Don't PanicDelivery & correctness

Exactly-once

Exactly-once semantics means every event counts once, even when a machine dies mid-flight and the event is redelivered.

Also called: effectively-once

RUNrows consumed, in orderCHECKPOINToffset + statekill -9resume · replay from the checkpoint offset
A crash resumes from the last checkpoint. The rows consumed after it are replayed from the recorded offset, so the run's output is byte-identical: nothing lost, nothing double-counted.

Exactly-once - the promise, sold under the name exactly-once semantics, that every event counts once even when a machine dies mid-flight and the event gets redelivered. It is the most oversold phrase in streaming, so read the fine print: nobody delivers a message exactly once. That is impossible the moment two computers have to agree over a network that can drop either the message or the acknowledgement, and you cannot tell which. What real systems do is deliver at least once and then arrange for the duplicates to change nothing: an idempotent producer tags retries, transactions fence zombie writers, and state folds into a checkpoint that either fully commits or does not exist. Which is fine. The effect is exactly once, and the effect is what your invoice totals care about.

Do you need it? Yes. You need your numbers to be right. You do not need three systems and a transaction coordinator to get there: ubik does it in one process with an atomic checkpoint, deterministic replay and an idempotent Kafka sink, and its CI compares a kill -9 run against a batch oracle, byte for byte.

Sources

Related