Idempotent
Applying an operation N times lands in the same state as applying it once. The principle that makes retries safe — and the truth behind 'exactly-once'.
Instances
- HTTP PUT / DELETE
- idempotency keys
- Kafka exactly-once
- DB upsert
The principle
An operation is idempotent if running it N times converges to the same state as running it once. It's not about avoiding side effects — it's about the side effect being repeatable without accumulating. DELETE /users/42 is idempotent; a naive POST /orders is not.
How it maps to practice
- HTTP semantics —
PUT,DELETE,GETare defined as idempotent;POSTis not. This is why a proxy can safely retry aGETbut not aPOST. - Idempotency keys — Stripe et al. have the client send a unique key per logical charge; the server dedupes on it. This is the standard fix for "did my payment go through?"
- "Exactly-once" messaging — mostly a marketing word. The honest mechanism is at-least-once delivery + idempotent processing. Kafka's "exactly-once" is dedup keyed on producer/sequence IDs — idempotency under the hood.
- DB upsert —
INSERT ... ON CONFLICT DO UPDATEmakes a write idempotent on the key.
The reason it matters: networks retry. A client that loses the response can't tell failure from success, so it resends. Idempotency is what makes that resend safe instead of a double-charge.
How it gets buried
"Exactly-once delivery!" sold as a property of a broker. It isn't — delivery is at-least-once, and processing is made idempotent. The buzzword hides where the work actually happens (your consumer).
Say it clearly
"Run it twice, same result. So we can retry safely." If a race-condition can let two first-time requests both slip through the dedup check, the key alone isn't enough — you need a distributed-lock or a unique constraint.
In Korean
"멱등(冪等)" — a math loanword ("same under repeated exponentiation"). Accurate but opaque; most people meet it as jargon and unpack it once. English idempotent (idem = same) wears its meaning on the surface.