Finance reports double-counted revenue from a pipeline the team believed could not repeat an effect — how do you decide which destinations to make repeat-proof and what the next notch costs?

## First, correct the claim the team is making The phrase in circulation is *exactly-once*, and the useful reading of it is narrow: **the destination ends up in the state it would have been in had the work run once, even though the work in fact ran twice** — nothing prevents the second delivery, the second delivery is simply made not to matter. Two consequences follow immediately, and both are usually what has gone wrong when a report like this arrives: - it names an **effect at a named destination**, not a property of a pipeline. Each hop earns it separately, and the chain is only as strong as the hop that earns it least; - it is not the same claim as **the engine's own accumulated state reflecting each record once after recovery**. That second claim is often true, is what most runtime documentation is describing, and is compatible with the destination holding a row twice — the rows left the process and were never part of the state that recovery restored. So the investigation is not "is the engine broken". It is "which hop writes in a way that a replay changes". ## Inventory the effects, not the services Walk the pipeline and write down every point where something becomes visible outside the job, and classify each: | Class | Example | What a replay does | What earning the promise costs | |---|---|---|---| | Rebuildable | A derived table replaced whole each run | Nothing, if the write replaces by key | Usually already free | | Accumulating | A running counter maintained by increment | Permanently wrong until someone recomputes | Rewrite as a recomputed value, or key plus replace | | Published once | An append-only landing area | A second copy every reader must handle | Reader-side deduplication, paid forever | | Unretractable | A payment, a message to a third party | Real-world duplicate | Caller-supplied identifier on the other side, or accept a risk | | Already consumed | A downstream job that read the duplicate | The damage propagated before you noticed | Notification and recomputation, not a write-side fix | The last row is the one that turns a technical fix into an incident. Correcting the table does not un-send the alert, un-fire the invoice, or un-snapshot the copy a downstream team took this morning. Any plan that stops at the row is incomplete. ## Price the next notch honestly Moving one destination from duplicate-tolerant to repeat-proof is not free, and the costs are predictable: 1. **Freshness.** If the mechanism is committing output and the recorded read position as one unit, output becomes visible only at commit boundaries. The destination's freshness is then set by the commit interval, not by the record rate — and shortening the interval to recover freshness raises per-commit overhead and, for a stateful job, the cost of taking recovery points more often. 2. **Storage and read cost.** Identifier columns, uniqueness constraints, deduplication views and the indexes underneath them. Reader-side collapsing is paid on every query by every consumer, for as long as the data exists. 3. **Coupling.** The design now depends on what the destination can do. Replace the destination and the guarantee has to be re-earned, which is a constraint on future architecture, not just on this job. 4. **Operational surface.** Staged output that must be published, intent records that must be reconciled, and a restart path with more states in it. Each is a thing that can be half-done at three in the morning. Runtimes also differ in how much they contribute: some offer destination integrations that arrange the coupling, some leave the whole construction to the author, and none can supply a key the record does not contain. Do not price this from the runtime you know best. ## Decide, write it down, and publish the exceptions The deliverable is not a mechanism, it is a short table: for each destination, which class it is in, what guarantee it carries, and who is told when it is duplicate-tolerant. Two organisational habits make it hold: - **Spend where the effect cannot be retracted or recomputed.** Money and messages first, accumulating counters second, rebuildable tables last — they usually cost nothing to fix and are the ones teams fix first because they are easy. - **State the tolerated case out loud.** A destination that may double-count during a replay is a perfectly reasonable design; a destination that may double-count and whose consumers were never told is the thing that produced this report. The answer to "why did finance see it twice" is almost never a broken recovery mechanism. It is that the promise was believed to be a property of the pipeline when it was only ever a property of a particular write, and nobody had written down which writes had it.