Evidlake
Menu

Idempotency

Also known as: idempotent, idempotent operation.

An operation is idempotent when doing it several times has the same effect as doing it once — which is what makes retries safe.

Updated Last reviewed

Synthetic dataExamples on this page use synthetic data created for illustration.

Definition

An operation is idempotent when running it several times leaves the system in the same state as running it once. Idempotent steps make retries safe: if you are unsure whether a step finished, you can simply run it again without doubling its effect.

In plain terms

Networks fail, jobs time out and people press the button twice. If the step is idempotent, the answer to “did that work?” can always be “run it again”. “Set the balance to 100” is idempotent; “add 100 to the balance” is not.

In data work, idempotency is usually achieved with a stable key: each record carries an identifier, and writing a record with an identifier that already exists replaces or ignores it instead of adding another copy.

Example

A file of 3 orders is loaded twice, by mistake.

Loading methodRows after the first loadRows after the second load
Plain append36
Write by order id (insert, or update if the id exists)33

The second method is idempotent: the repeat changes nothing. Note that a correction is still possible, because a changed record with the same id replaces the old one.

Common misunderstandings

  • “Idempotent means nothing happens the second time.” The system may do the work again; what matters is that the resulting state is the same.
  • “Only GET requests are idempotent.” In HTTP, PUT and DELETE are also defined as idempotent, while POST is not by default.
  • “Retries plus idempotency give exactly-once delivery.” They give effectively once processing: messages may still arrive twice, but the second one has no extra effect.
  • At-least-once Delivery

    A delivery guarantee under which every message or job arrives one or more times, never zero — so duplicates are possible and must be tolerated.

  • Append-only Ledger

    A record store that only ever adds rows: corrections are new rows that point at the ones they replace, so history, including the mistake, stays readable.

References

  1. R. Fielding, M. Nottingham, J. Reschke. RFC 9110: HTTP Semantics, section 9.2.2 Idempotent Methods . IETF, 2022.
  2. Martin Kleppmann. Designing Data-Intensive Applications . O'Reilly Media, 2017. ISBN 978-1449373320.