What belongs in an organisation-wide retirement standard so that deleting a stream stops being a bespoke, risky event?
answer
- make the irreversible step boring
- a rule, not a fixed number of days
- rehearse before removing anything
- the standard must be the fast path
- bounded accepted risk, not zero risk
basics
~20 sA fixed sequence nobody re-invents, minimum durations tied to the slowest consumer rather than an arbitrary number of days, the delete as its own dated change, a reversible rehearsal before it, and a named person who may shorten any of it.
solid answer
~40 sThe aim is to make the irreversible step boring. A workable standard fixes five things: the **sequence** (replacement live, dual publication, readers, writers, silence, wait, delete) so no team invents one under time pressure; the **durations**, expressed as "at least one cycle of the slowest known consumer" rather than a flat number; the **separation** of the delete into its own change on its own date, executed by a deliberate act rather than as the runbook's last line; a **reversible rehearsal** — withdraw the write grant, then the read grant, leave the records in place, and see who complains; and an **override** clause naming who may compress the schedule and what they must record. Then make that path faster than doing it by hand, or it will be routed around.
go deeper
The takeaway is that retiring a stream should follow the same written steps every time, so that the delete at the end is a routine act rather than a decision someone makes under pressure.
Be able to list the standard's contents — fixed sequence, duration rule, delete as its own change, rehearsal, override — and explain why a flat number of days is a weaker rule than one tied to the slowest consumer.
Show how you would operate it: the rehearsal that turns a silent permanent failure into a loud reversible one, and the machinery that makes the standard quicker to follow than to bypass.
The call is how much residual risk the organisation buys with how much delay, who is entitled to accept it, and whether safety comes from communication or from mechanism — which depends on how many teams there are and who pays for the stored bytes.
## What a standard is actually for Most estates retire streams rarely enough that nobody has done it twice. Each retirement is therefore designed from scratch, under schedule pressure, by whoever inherited the stream — and the step that gets compressed is always the wait, because the wait is the part that visibly costs time and invisibly buys safety. A retirement standard exists to move that decision out of the moment. Its job is not to describe good practice; it is to make the **irreversible step boring**: pre-decided, pre-scheduled, and separated from everything that felt urgent. ## The clauses that carry the weight 1. **A fixed sequence.** Replacement stream live; dual publication opens the cut-over window; reading groups moved one at a time; writers moved; dual publication stopped; quiet period; delete. Publishing the sequence removes the most common failure — deleting in the same change as the cut — without requiring anyone to be clever at 2 a.m. 2. **Durations expressed as a rule, not a number.** "At least one full cycle of the slowest known consumer, plus margin" travels across a stream read every second and a stream read every quarter. A flat fourteen days is simultaneously too slow for the first and dangerously fast for the second, and teams learn to disregard numbers that are obviously wrong for their case. 3. **The delete as its own change.** Separate date, separate approval, separate execution. This buys a second decision point after all the evidence is in, and it stops the delete inheriting the momentum of a successful cut-over. 4. **A reversible rehearsal.** Before removing anything, withdraw the write grant, then the read grant, and leave the records untouched for a stated period. Anything that still depends on the stream now fails with an access error — loud, attributable and undone in seconds. This is the closest thing to a dry run that an irreversible operation permits, and it is the single highest-value clause in the standard. 5. **An override with a name attached.** Schedules sometimes genuinely must be compressed. The standard should say who may do it and what they must record, because an unwritten override is used constantly and an impossible one is simply ignored. 6. **A record of the delete itself.** The replacement's name, the window dates, who was notified, the volume and the last record time removed, and the residual risk accepted. When something fails months later this is the only account of what happened to its input. ## Why the standard must be the fast path A standard that people route around is not applied to the retirements that matter most, because the ones performed in a hurry are exactly the ones under pressure. The practical consequence is that the standard has to come with machinery, not just prose: a declared retirement in version control that a pipeline executes on the stated dates, a pre-written announcement, and a one-line way to open dual publication. If following the standard is slower than doing it by hand, the estate's most dangerous deletes will be the hand-made ones. | Clause | What it prevents | What it costs | |---|---|---| | Fixed sequence | Cut and delete collapsing into one change | Nothing; it is a document | | Duration rule | A schedule shorter than a periodic consumer's cycle | Weeks of duplicate storage | | Delete as its own change | Momentum carrying an unverified delete through | One extra approval | | Reversible rehearsal | A silent, permanent failure | A short, visible, reversible one | | Named override | Quiet non-compliance | An explicit, recorded risk decision | ## What a standard should not try to do It should not try to decide **whether** a stream is retired — that judgment belongs to the people who own it. It should not enumerate platform commands, because an estate usually runs more than one platform and the sequence is the portable part. And it should not pretend that a long enough wait removes risk: a sufficiently occasional consumer can outlast any schedule, so the standard's real output is a **bounded, recorded, accepted** risk rather than the absence of one. ## Where organisations legitimately differ An organisation with a strict regulatory footprint may hold streams indefinitely and never execute the delete at all, making the standard a retention decision in retirement's clothing. One paying by stored volume on a rented cluster has a live incentive to complete the delete, and will tolerate a shorter wait to get it. A small estate with three teams who all know each other can lean on the announcement; one with three hundred teams cannot, and must lean on the rehearsal instead. The sequence is the same everywhere; what varies is how much of the safety comes from communication and how much has to come from mechanism.
- Why is withdrawing access before deleting more valuable than one more week of waiting?Waiting only helps if something happens to run during it, and nothing signals that it did. Withdrawing the read grant converts every remaining dependency into an immediate, attributable failure, and restoring the grant undoes it in seconds. It turns a passive hope into an active test while the records are still there.
- How should a standard handle a stream whose owning team no longer exists?By naming a default decision-maker rather than stalling. Someone — a platform team or an architecture function — must be entitled to accept the residual risk on behalf of an absent owner, on the record. Otherwise the standard's only possible outcome for such a stream is indefinite retention, which is how estates accumulate the things nobody will ever delete.
- Should a standard mandate dual publication for every retirement?No. For a stream with a single known consumer, stopping the writer, letting it finish, then switching both is simpler and creates no duplicate records. A better rule is to mandate the sequence and let dual publication be required only where consumers are multiple, unknown, or cannot move simultaneously — with the exemption recorded.
saying these in an interview costs you the question
- Mandates a flat waiting period for every stream in the estate
- Puts the delete in the same change as the cut-over
- Writes a standard slower than retiring a stream by hand
- Treats an approved delete as somehow recoverable
- Forbids any override, so the schedule is quietly ignored