skip to content

When retiring a stream onto a replacement, in what order do the steps run, and why is the delete held back?

level: middleimportance: must knowfreq 55%

answer

  1. the sequence is the safety
  2. both streams written before anyone moves
  3. readers move, then writers
  4. silence before the delete
  5. the delete is its own change

basics

~20 s

Stand the replacement up, write every record to both, move readers across, move writers, stop dual publication, wait out a quiet period, then delete. The delete goes last, and alone, because it is the one step nothing undoes.

solid answer

~40 s

A retirement is a sequence, and the sequence is the safety. First the replacement stream exists and can be written and read. Then writers publish every record to both streams — `dual publication` — which opens the cut-over window. Only inside that window are readers moved across, one reading group at a time, and confirmed to be making progress on the replacement; that is the cut. Writers are then pointed at the replacement alone, dual publication stops, and the old stream goes silent. A deliberate quiet period follows, long enough to contain the slowest consumer that might still be attached, and only afterwards does the delete happen, as its own change on its own date. Every step before the delete is undone by pointing a client back; the delete is undone by nothing.

go deeper

for a junior

Recall the shape: a new stream is stood up, traffic runs to both for a while, everything is moved across, and the old one is deleted last. The delete is the step that cannot be taken back.

for a middle

Explain why each step precedes the next — dual publication before any reader moves, readers before writers, silence before the delete — and why the delete is scheduled as its own change rather than the final line of the cut-over.

for a senior

Show that you plan the retirement around undo cost: name what each step costs to reverse, what the quiet period is listening for, and what you would do on finding an unknown consumer mid-window rather than after the delete.

for a principal

The angle is standardisation. Argue whether your organisation should mandate this sequence for every stream, what the minimum durations should be tied to, and who is allowed to shorten them — the cost of a bespoke retirement is paid once per stream, forever.

## What a retirement actually is A **stream** here means any named, durable channel an organisation provisions, names, owns and eventually takes out of service — log-shaped, where records stay readable after delivery, or queue-shaped, where a delivered message is gone. Retiring one is not a delete with paperwork wrapped around it. It is a **move**: readers and writers are relocated onto a **replacement stream**, and only once nobody is left is the original removed. Two moments get called the same thing, and keeping them apart is most of the discipline. **The cut** is the moment readers are considered moved onto the replacement. **The delete** is the separate, later step that destroys the stream and everything still stored in it. Teams that use one word for both perform both in one change, and that is where retirements turn into incidents. ## The order, and what each step is for 1. **The replacement stream exists and is operable.** It can be written to and read from before anyone depends on it. Nothing later in the sequence is safe if the replacement is still being argued about. 2. **Dual publication begins.** Every writer publishes each record to both the old stream and the replacement. This opens the **cut-over window**: for its whole duration, either stream carries the full traffic. 3. **Readers move, one reading group at a time.** Each is pointed at the replacement and confirmed to be making progress there before the next is touched. This is the cut. A reading group does not resume "where it was" — it starts wherever you deliberately place it, which is its own decision. 4. **Writers move to the replacement alone.** Only after the readers, never before: writers that leave first turn the old stream silent while consumers are still attached to it. 5. **Dual publication stops.** The old stream now receives nothing and holds only what it already had. 6. **A deliberate quiet period.** Nothing is done. The estate is given time to notice something it missed, while noticing is still cheap. 7. **The delete.** Its own change, its own date, executed on the strength of a decision already made. The ordering mistake that actually happens in the field is step 3 before step 2: a reading group is pointed at a replacement that nothing is writing yet, it sits idle, and the operator concludes the move worked because there are no errors. ``` replacement live ──┬── dual publication running ──┬── writers moved ──┬── quiet period ──┬── DELETE │ │ │ │ └── readers move (the cut) both streams old stream no way inside this window carry traffic silent back ``` ## Why the delete is held back Time is the mechanism. Every step before the delete fails **loudly and cheaply**: a client is pointed back, and the worst outcome is a gap of minutes. The delete fails **silently and permanently** — the failure surfaces whenever the next consumer of those records happens to run, which may be weeks later, and by then there is nothing to point anything at. | Step | If it proves wrong | Cost to undo | |---|---|---| | Replacement created | remove it | minutes | | Dual publication running | stop it | minutes, plus the duplicate storage it charged for | | A reading group moved | point it back at the old stream | minutes | | Writers moved | point them back | minutes | | Dual publication stopped | restart it | minutes; the old stream simply missed that interval | | Quiet period elapsed | extend it | nothing at all | | **The delete** | **nothing works** | **the records are gone** | Because the two sides of that table are so unequal, the delete is made a separate change with its own date rather than the last line of the cut-over runbook. A separate change is also a separate chance to cancel. ## What the quiet period is listening for Once dual publication stops, the old stream is a silent, intact record of what used to flow through it. Anything still attached to it now produces a visible symptom — a consumer with nothing to do, a report that comes back empty, a person asking why. Every one of those is a last cheap failure, and every one of them is repaired by re-pointing the consumer at the replacement. The length of the quiet period is therefore not a ritual number; it is a bet about how long the slowest thing that reads this stream takes to come round again. ## Where platforms differ - **Log-shaped platforms**, where records remain readable after delivery, let a consumer found during the quiet period be moved and still read the history on the old stream, for as long as those records are still held. The quiet period is genuinely a grace period. - **Queue-shaped platforms**, where a delivered message is gone, have far less to hand back: the old stream holds only what was never delivered, so the value of the wait is the warning, not the data. - Platforms differ in whether storage is reclaimed immediately on delete, and in whether the freed name can be reused at once. Neither difference brings the records back, so neither changes the sequence. The standard that survives contact with a real estate is therefore short: replacement first, both streams written, readers, writers, silence, wait, delete — and the delete is always somebody's separate decision on a separate day.

  • Why must dual publication start before the first reading group is moved rather than afterwards?
    Because a reading group pointed at a stream nothing is writing has nothing to read, and the silence is indistinguishable from success. Starting dual publication first means the replacement already carries live traffic when the first consumer arrives, so "it is making progress" is a real signal rather than an absence of errors.
  • A consumer nobody knew about is discovered halfway through the cut-over window. What is the cheapest response?
    Nothing urgent. While the window is open both streams carry every record, so the consumer is working correctly where it is. Schedule its move like any other, decide where on the replacement it should start, and extend the window if it cannot be moved in time. The cost of extending is duplicate storage, which is small next to a deleted stream.
  • Is dual publication ever the wrong tool for a retirement?
    Yes. Where a stream has a single known consumer and a short planned pause is acceptable, stopping the writer, letting the consumer finish, then switching both to the replacement is simpler and creates no duplicate records anywhere in the estate. Dual publication earns its cost when consumers are many, unknown, or cannot be moved at the same moment.

Moving a shop into a new unit: you open the new unit, run both for a season, move the regulars, then the suppliers, then lock the old door and leave the building standing for a month. Demolition is booked separately, once nobody has knocked.

saying these in an interview costs you the question

  • Deletes the old stream in the same change as the cut
  • Moves writers first, starving consumers still on the old stream
  • Points a reading group at a replacement nothing is writing yet
  • Calls the retirement finished once the replacement is serving traffic
  • Believes a deleted stream can be reconstructed from its replacement