The promise that cannot be kept
Messaging systems often advertise exactly once delivery, meaning each message is delivered one time, never lost and never duplicated. Over an unreliable network this is impossible to guarantee for the raw act of delivery.
Why delivery cannot be exactly once
The sender faces a dilemma. After sending, it waits for an acknowledgement. If the ack is lost, the sender does not know if the message arrived. It must choose:
- Resend, risking a duplicate if the first copy did arrive.
- Stay silent, risking a loss if the first copy did not arrive.
No protocol escapes this fork because the failure is in the channel itself, not the endpoints.
What is actually delivered
Real systems offer at least once or at most once delivery. The trick is to add idempotent processing or deduplication on top. The combination of at least once delivery plus exactly once processing gives the effect users want, even though the wire still carries duplicates.
Key idea
Exactly once delivery is a myth, but exactly once processing is achievable by combining at least once delivery with idempotency or deduplication.