Dual publication writes every record to both the old stream and its replacement during a cut-over: what does it protect, and what does it not?

## What dual publication buys During a retirement there is a period when the old stream and the **replacement stream** both receive every record. That period is the **cut-over window**, and the practice of writing to both is **dual publication**. Its purpose is to make one hard, atomic-looking change — "everything moves to the new stream" — into a series of small, independent, reversible ones. Concretely it buys four things: - **Independence.** Readers and writers no longer have to move in the same change, or even the same week. - **Granularity.** Reading groups move one at a time, each verified before the next is touched. - **Reversibility.** A move that goes badly is undone by pointing the client back at the stream it came from, which still has everything. - **Tolerance of ignorance.** A consumer nobody remembered keeps working, because the stream it reads is still being fed. A missed consumer becomes a scheduling problem instead of an outage. That last one is the real reason the practice exists. Estates do not have perfect knowledge of who reads what, and dual publication converts that imperfection from a hazard into a delay. ## What it does not carry: progress Dual publication copies **records**. It does not copy the bookkeeping that says how far a consumer had got. Where a reader owns a stored position, that position is a coordinate in one stream. The same record occupies a different coordinate in the replacement, and nothing reconciles the two. So a reading group moved during a cut-over does not resume; it is **placed**. There are exactly two honest choices, and they have opposite failure modes: | Where you place it | What you get | What it costs | |---|---|---| | At the replacement's earliest available record | No gap: everything the replacement holds is processed | Overlap: records already handled on the old stream are processed again | | At the replacement's newest record | No repeats | A gap: whatever arrived between the start of the window and the move is never read from either stream | There is no third option that gives neither, because there is no correspondence between the two streams' positions to exploit. Which one you pick is a property of the consumer, not of the retirement: work that is safe to repeat takes the overlap, work that must not be repeated takes the gap and someone backfills it deliberately from another source. On platforms where a **delivered message is gone**, the question dissolves in a different direction: there is no stored position to move, and the equivalent decision is whether the old stream is drained before its writers leave, or whether whatever is left in it at the end is simply accepted as lost. ## The duplicate the window creates For the length of the window, each business event exists twice in the estate — once on each stream. That is harmless **only** while every consumer reads exactly one of them. A consumer attached to both, or a consumer moved without being detached from the old stream, performs its work twice. Dual publication offers no protection whatsoever here: it is a publishing technique, not a deduplication mechanism, and whether double processing is survivable is a property of the consumer, decided long before this retirement started. The same duplication is a cost: the records are stored twice and, on a rented cluster, usually charged twice. That cost is the budget for the whole safety property, and it is small compared with a deleted stream, which is why an extended window is nearly always the right answer when something unexpected turns up. ## What it stops protecting, and when The protection has a clean end date. The moment dual publication stops, the old stream receives nothing. From then on: - A consumer still attached to the old stream gets silence, not traffic. That is the warning the quiet period is for. - On a log-shaped platform, what the old stream already holds stays readable until the delete, so a late discovery can still read history there. - On a queue-shaped platform, there was never much left behind to read. - After the delete, none of this applies — there is no stream to point anything at, and the question becomes where else the data exists. ## Where platforms differ The practice is portable; the detail is not. Where a stream is split into parts and readers own a rewindable numeric position, placement is an explicit operational choice and the gap-or-overlap table above is exactly the decision. Where consumers compete for messages that vanish on acknowledgement, the move is about draining rather than placing. Some platforms let a consumer be attached to two streams effortlessly, which makes the double-processing hazard easier to hit. The single claim that holds everywhere is the one worth remembering: **both streams carry the records, and neither carries the progress**.