Idempotency

An operation is idempotent if performing it multiple times has exactly the same effect as performing it once. Setting a light switch to "on" is idempotent — flipping it to "on" five times leaves it exactly as on as flipping it once. Pressing "add one item to cart" is not — pressing it five times adds five items. This one property turns out to be one of the most load-bearing concepts in distributed API design, because it's the difference between "safe to retry" and "dangerous to retry."

Why this comes up constantly: networks fail silently

Here's the scenario that makes idempotency unavoidable rather than optional: a client sends a POST /payments request, the server processes the payment successfully, and then the response is lost on the way back — a timeout, a dropped connection, a proxy restart. From the client's point of view, it has no way to distinguish "the request never arrived" from "it arrived and succeeded but the response got lost." The only safe general strategy is to retry. But if the original request did succeed, a naive retry charges the customer twice.

System Design Lab

This is exactly the same uncertainty that motivates Webhooks to require idempotent handling on the receiving end — any at-least-once delivery guarantee (retries on timeout, message queue redelivery) inevitably means duplicates are possible, so the receiver has to be able to absorb them safely rather than assume delivery is exactly-once.

Idempotency keys: the standard mechanism

For an operation that isn't naturally idempotent (like "charge a card" or "place an order"), APIs commonly make it artificially idempotent using an idempotency key: the client generates a unique key (a UUID) once per logical operation and sends it with the request. The server records which keys it has already processed and, if it sees the same key again, returns the stored result of the original attempt instead of executing the operation a second time.

The discipline this requires is on the client: it must reuse the same key across retries of the same logical attempt, and generate a new key for a genuinely new operation. Get that wrong in either direction and the safety guarantee disappears — reuse a key for a different operation and it gets silently dropped; generate a new key on every retry and duplicates go right back to happening.

Which HTTP methods are idempotent by design

Part of the HTTP specification itself classifies methods by whether repeating them is supposed to be safe — this is worth knowing cold, since it comes up directly in APIs:

Method	Idempotent?	Why
GET	Yes	Read-only, no state change
PUT	Yes	Replaces a resource with a given value — repeating it sets the same final state
DELETE	Yes	Resource is gone after the first call; calling again is still "gone"
PATCH	Depends	Idempotent if it sets absolute values; not if it means "increment by 1"
POST	No, by default	Typically means "create a new thing" — repeating it creates more things

This is exactly why POST is the method that most commonly needs an explicit idempotency key layered on top — the protocol itself makes no safety promise for it, unlike GET, PUT, and DELETE.

Idempotency and retries go together

Idempotency is what makes automatic retries — at any layer, from a client's HTTP library to a message queue redelivering an unacknowledged message — safe to do blindly. Without it, every retry policy has to reason carefully about whether the previous attempt might have partially succeeded, which is exactly the kind of subtle correctness bug that's easy to get wrong under pressure. This is also why idempotency is treated as a form of fault tolerance: it doesn't prevent failures, but it makes the standard recovery mechanism — just try again — safe by construction rather than by careful accounting.

Why this matters in an interview

Any design involving payments, order creation, or anything with a real-world side effect should proactively mention idempotency keys — it's a specific, well-known answer to "what happens if the client's request times out and it retries?" that shows you're thinking about failure modes, not just the happy path. It's also a cheap way to demonstrate precision: correctly identifying which HTTP methods are idempotent by spec, and which need help, is a fast signal of fluency.

Enforcing idempotency with client-generated keys: pros and cons

Pros

• ✓Makes retries safe for operations that aren't naturally idempotent, like payments
• ✓Client and server share a simple, well-understood contract (one key per logical attempt)
• ✓Lets the server return the original result instead of erroring on a duplicate

Cons

• ✕Requires the server to store seen keys, typically with an expiry policy
• ✕Correctness depends on the client reusing keys correctly across retries
• ✕Adds a bit of latency and storage cost to every request that uses it

Further Reading

• Stripe — Idempotent requests — a widely referenced production implementation of idempotency keys.
• MDN Web Docs — Idempotent methods — a concise definition tied directly to the HTTP method specification.