The source cluster is lost and its uncopied tail dies with it, so what does that gap cost the systems downstream?

## The tail that dies with the source cluster The **uncopied tail** is the set of records that existed on the source cluster and had not reached the target cluster when the source was lost. It is tempting to think of it as data in flight that will turn up later. It will not. The copier reads from a cluster that is gone; there is no queue somewhere still draining. Those records have exactly one property that matters: they were **acknowledged to their writers**, and they now exist nowhere. That asymmetry is the whole cost. The producing side got a success and moved on — it marked an order placed, released a lock, returned a 200, deleted its own copy of the payload. The consuming side never sees the record at all. ## Why the gap is silent Nothing about a missing tail announces itself, and this is what turns a known loss window into an incident weeks later. - Readers that resume on the **target cluster** see a continuous stream. Where the stream is split into parts with their own position numbers, those numbers on the target are the target's own and run unbroken; where records are removed on acknowledgement, the missing items simply never appear. Either way there is no hole to trip over. - No component is responsible for noticing. The copier is gone with the cluster it was reading. The target cluster was never told what it did not receive. - Downstream systems are usually self-consistent afterwards. A projection built from a stream that is missing five thousand records is not corrupt; it is just wrong, and it looks fine. The practical consequence is that the loss surfaces as a reconciliation difference — a count that does not match, a customer who insists they placed an order — rather than as an alert. ## What it costs, stream by stream The stated loss window is the same for every stream on the hop, but what it *costs* is not. The useful question is whether the stream is the system of record for those facts or a derived view of something that survives elsewhere. | What the stream carries | What the tail's loss costs | Can it be repaired? | |---|---|---| | Facts whose only durable home is the stream (events captured at the edge, one-shot commands) | Permanent, unbounded — the fact is simply gone | No, except from whatever the writer still holds | | A shadow of state held in a writer's own store (change records emitted from a database) | Temporary divergence in every derived consumer | Yes — re-emit from the writer's store, or re-derive the consumer | | High-volume telemetry or metrics | A gap in charts and aggregates | Usually not worth repairing; the cost is accepted | | Instructions that cause external side effects (payments, notifications) | The side effect never happens while upstream believes it did | Only by reconciliation against the external system | ## Repairing what can be repaired There are exactly two honest repair routes, and neither one involves the stream: 1. **Re-emit from a source that survived.** If the writer holds its own durable state — a database whose change records became the stream, a request log — the tail can be regenerated. This is the single strongest argument for having writers keep state rather than treating the stream as the only ledger. 2. **Reconcile against the external world.** Where the records caused or recorded effects outside your systems, compare the downstream state to the external system of record and repair the difference by hand or by a targeted job. What does *not* work is replay. Replay reads from a stream, and the records were never on the surviving one. ## What this changes about the target you state This is why a stated recovery point is a per-stream decision and not an estate-wide one. A stream carrying change records from a durable store can genuinely afford thirty seconds of loss, because thirty seconds of divergence is repairable and the repair is understood. A stream that is the only home of a business fact cannot afford it in the same way, and the honest responses are narrow: - Give that stream a much tighter loss window, at whatever the copier capacity costs. - Move it to a synchronous cross-site write and pay the round trip on every write. - Give the writer a durable store of its own so the stream stops being the system of record — usually the cheapest of the three. - Or state the number plainly, in records, and get the owning team to say out loud that they accept it. An interviewer is listening for the last one as much as the first three. Naming the cost and getting it accepted is a real answer; assuming the loss is recoverable is not.