Idempotency.
Pressing the elevator button twice does not call two elevators.
An operation is idempotent if doing it twice has the same effect as doing it once. Pressing an elevator button, setting a light switch to "on", saving a file with the same contents — all idempotent.
This sounds academic until you remember that networks are unreliable, and unreliable networks force you to retry.
- Come on, come on…1
You press the elevator button. Press it again, impatiently, and again — still one elevator comes.
- 2
That’s idempotent: doing it twice has the same effect as doing it once.
- 3
Now the dangerous kind: “add £10 to the order.” Sent once, +£10. Sent twice, +£20.
- Did that go through?4
Networks are flaky. You send a request, the reply never comes — did it work? You can’t tell, so you retry.
- Why was I charged twice?!5
A naive retry of “add £10” charges you twice. That’s how people get double-billed.
- Seen this key — returning the first result.6
The fix: tag the request with a unique key. The server remembers it and ignores the duplicate.
Why retries are unavoidable
When you send a request and the reply never comes back, you are stuck: did it succeed and the confirmation got lost, or did it fail entirely? You cannot tell. The only safe move is to try again — but if the first one actually worked, a naive retry does the action twice.
That is how people get charged twice or end up with duplicate orders. Idempotency is the cure.
The idempotency key trick
For operations that are naturally repeat-unsafe (like a payment), the client attaches a unique id to the request. The server remembers ids it has already processed, so if the same id arrives again it recognises the duplicate and returns the original result instead of doing the work twice.
This is exactly how payment APIs let you retry safely after a timeout.