Networks fail in the worst possible way: a request succeeds, but the response gets lost, so the client does not know whether it worked. Should it retry? Idempotency is the property that makes the answer "yes, safely". It is a quietly essential concept for building reliable systems, and this guide explains it.
The definition
An operation is idempotent if performing it multiple times has the same effect as performing it once. Setting a value to 5 is idempotent — do it ten times and the value is still 5. Adding 1 is not — repeat it and the total keeps climbing. The distinction matters the instant a network forces you to consider retrying.
Why it matters
When a response is lost, a client that retries a non-idempotent operation risks doing it twice — charging a card twice, creating two orders, sending two emails. If the operation is idempotent, the retry is harmless, because the second attempt changes nothing. Idempotency turns "I am not sure, so I dare not retry" into "retry freely".
HTTP and idempotency
By design, GET, PUT and DELETE are idempotent, while POST is not. This is why a browser warns you before re-submitting a POST form but happily reloads a GET page. Designing your API to honour these semantics lets clients, proxies and load balancers retry safely where it is allowed.
Idempotency keys
For operations that are inherently not idempotent — like creating a payment — well-designed APIs use idempotency keys. The client generates a unique key (often a UUID) and sends it with the request. The server records it, and if the same key arrives again, it returns the original result instead of acting twice. This makes even a "create" safe to retry, which is why payment APIs rely on it.
The takeaway
Idempotency is what makes a distributed system trustworthy in the face of unreliable networks. Use idempotent methods where you can, and idempotency keys where you cannot, so that a lost response never turns into a duplicate action.