Idempotency Prevents Duplicates
What happens when a request succeeds but the reply never arrives?
The idea
An idempotent operation produces the same result whether it runs once or many times.
In the real world
A payment request carries a unique key so a retry cannot charge twice.
Going deeper
The problem is not that requests fail. It is that a request can succeed while the response is lost, leaving the client unable to distinguish success from failure — and the only safe thing it can do is try again.
The fix is to let the server recognise a repeat. The client generates a key once, before the first attempt, and sends the same key on every retry. The server records it with the result, so a second arrival returns the original outcome rather than performing the action again. Note that the key must be created by the caller and reused, not regenerated per attempt, which is the usual implementation mistake.
Where it stops applying
Idempotency keys need storage and an expiry policy, and the window has to outlive plausible retries. It is worth the machinery for payments and orders, and overkill for actions that are harmless to repeat.
Why it matters
Networks retry on their own, so anything that must not happen twice needs a way to recognise a repeat.
Try this today
Find one write in your system that a retry would duplicate, and give it a key.
Test yourself
A payment succeeds, the response times out, and the client retries. Why does adding a unique key to the request fix this, when validating the amount would not?
Show the answer
The key lets the server recognise the second call as the same operation and return the original result instead of performing it again. Validation only checks that the request is well-formed; it cannot tell a genuine second payment from a repeat of the first.
Learn this in the feed Answering from memory, then again days later, is what makes it stick.