Idempotency & Exactly-Once Illusions
You'll learn to
- -Explain why "exactly-once" delivery is mostly a myth, and how idempotency fixes it
Why "Exactly-Once" Is Mostly a Myth
Back in the Asynchronous Systems module, at-least-once delivery was named as the practical default for most queues, and the same reality applies to retries in general: a network timeout doesn't tell you whether the server actually processed your request or not, so a client retrying "to be safe" might be sending a duplicate of a request that already succeeded.
Idempotency Keys
The fix isn't preventing duplicates: it's making duplicates harmless. The client generates a unique key for each logical operation (a specific payment attempt, say) and sends it with the request. The server remembers keys it has already processed and, if it sees the same key again, returns the original result instead of executing the action a second time, so retrying a payment can never double-charge the customer.
This is the same idea from the Dead Letter Queue chapter, applied at the request/response level instead of the message-queue level: "exactly-once" in practice almost always means "at-least-once delivery, with an idempotent receiver."
The server checks the idempotency key against a store of already-processed requests before executing anything new.
Interview Signal is part of Pro
See a real weak answer next to a real strong one for this exact topic.
Quiz is part of Pro
Test what you just read with a short quiz, and bank the XP.
Level 17: Hotel Reservation is a textbook SAGA/resilience exercise.