Idempotence

An operation is idempotent if applying it more than once has the same effect as applying it once. In unreliable systems, where a request may be retried after an uncertain failure, idempotence is what makes retries safe.

Why it Matters

Because a client often cannot tell whether a failed request actually took effect, it must retry, and without idempotence retries duplicate the effect, double charges, double inserts. Idempotence is the practical foundation of "exactly-once" semantics, which are really at-least-once delivery plus idempotent processing.

Signals

• Retried requests causing duplicate side effects.
• "Exactly once" claimed with no dedup key or idempotency mechanism.
• Operations safe to repeat (set x = 5) versus not (add 5 to x).

Benefits

Safe retries, simpler failure handling, and a route to effectively-once processing on top of unreliable, at-least-once delivery.

Risks

Assuming an operation is idempotent when it is not; idempotency keys that are not actually unique, or are dropped under concurrency.

Tensions

Making operations idempotent adds state to track (keys, dedup tables) and design effort; naturally non-idempotent actions must be wrapped, which costs complexity.

Examples

A payment request carrying an idempotency key so a retry is ignored if the first attempt succeeded; an upsert that yields the same row whether it runs once or three times.