You’re sending a $10,000 check. Regular mail might get lost. Send two copies, recipient might cash both. What you need: tracked, signed for, proof of delivery. Your check arrives exactly once. Not zero times, not twice. Exactly once.
That’s the exactly-once delivery guarantee in distributed systems, and it’s harder than it sounds.
The Delivery Spectrum
At-Most-Once
Drop your letter in the mailbox and hope:
- Might arrive
- Might get lost
- No tracking, no guarantees
Simple for sender. Terrible for critical messages.
At-Least-Once
Keep sending until confirmed:
- Send letter
- No confirmation? Send again
- Still nothing? Send again
- Repeat until acknowledged
Guarantees arrival. But recipient might receive five identical checks.
Exactly-Once
The gold standard:
- Unique tracking number
- Signature required
- Delivery confirmation
- Duplicate detection
- One and only one delivery
Complex and expensive. Often misunderstood.
Implementation
Unique Identification
Every letter gets a unique ID:
Letter #2024-11-15-001:
- From: Alice
- To: Bob
- Content: $10,000 check
- Status: In Transit
This ID is permanent and globally unique.
Sender Tracking
Alice maintains a ledger of sent letters:
- Letter #2024-11-15-001: “Sent, Awaiting Confirmation”
- Letter #2024-11-14-017: “Delivered, Confirmed”
- Letter #2024-11-13-042: “Delivered, Confirmed”
Alice knows exactly what she’s sent and its status.
Receiver Registry
Bob keeps his own record of received letters:
- Letter #2024-11-14-022: Already received from Carol
- Letter #2024-11-13-055: Already received from Dave
- Now checking if #2024-11-15-001 is already in his log…
When letter arrives, Bob checks: “Have I seen this ID before?”
The Handshake
This diagram requires JavaScript.
Enable JavaScript in your browser to use this feature.
Failure Scenarios
Network Hiccup
Bob receives the letter, signs for it, but confirmation gets lost:
Alice sees: Letter #001: Sent, Awaiting Confirmation… still no confirmation… resends!
Bob’s mailbox: First #001 arrives, accepts. Second #001 arrives, “already have it,” rejects. Sends confirmation again.
Result: Letter delivered exactly once despite network failure.
Impatient Sender
Alice panics after 5 minutes, resends #001 again and again.
Bob: First #001 accepts, processes check. Second #001: “already have it,” rejects. Third #001: “still have it,” rejects.
No matter how many times Alice sends, Bob processes exactly once.
System Crash
Bob’s system crashes after receiving but before confirming:
- Letter #001 arrives
- Bob logs receipt
- Bob starts processing check
- CRASH
- Bob restarts
- Sees #001 in log
- Resumes from where left off
- Sends confirmation
ID tracking survives the crash.
Hidden Complexities
Deduplication Window
Bob can’t remember every letter forever:
Keep all IDs forever? Storage explodes. Forget old IDs? Might reprocess.
Solution: Deduplication window of 30 days. After that, assume no duplicates coming. Trade-off: Very late retries might duplicate.
Idempotency
Bob’s processing must be idempotent:
Processing check #001 twice must equal processing once:
- Don’t: Add $10,000 to balance
- Do: Set balance to specific amount
- Or: Check if already processed
Without idempotency, exactly-once delivery isn’t enough.
Decision Rules
Exactly-once comes with overhead: ID generation, duplicate checking, confirmation waiting, state management.
Choose exactly-once when:
- Duplicate processing causes real problems
- You can afford the complexity
Choose at-least-once when:
- Duplicates are acceptable (analytics, logging)
- Simplicity matters more
Choose at-most-once when:
- Occasional loss is acceptable (metrics, monitoring)
The art is knowing which guarantee fits your use case.