The reply disappears after the commit

A payment service records a charge. Its reply is lost. The client sees a timeout and repeats the call. The second call is not stale; it may be a second perfectly current charge.

An operation is idempotent when applying it twice has the same relevant effect as applying it once: $f(f(x))=f(x)$. Setting a profile field to a value may have this property; incrementing a balance does not. But a locally idempotent function does not automatically make an external protocol safe—notifications, charges, and audit events may remain duplicated observations.

An idempotency key names the logical operation. The receiver stores the first terminal result under that key and returns it for repeats. The law is keyed settlement uniqueness: one admitted key corresponds to at most one committed effect and one replayable result.

When retaining keys is impossible or the outcome can be learned independently, reconcile: query by operation identity, compare desired and observed state, then issue only the missing action. “At most once” transport is not a promise ordinary networks can conjure after an ambiguous failure; receiver state closes the uncertainty.

Where the model stops

Do not attach idempotency machinery to cheap read-only queries merely because they retry. Do not reuse a key for a changed payload. The receiver must either reject mismatched reuse or bind the key to a canonical request digest.

Lessons

• Timeout means unknown settlement, not known failure.
• Idempotence is a law over effects, not a synonym for retry.
• Stable operation identity lets the receiver recognize repetition.
• Reconciliation is the fallback when settlement can be observed afterward.

Practice

1. Give an idempotent and non-idempotent operation from the same API.
2. Explain why a generation fence cannot prevent a duplicate charge.
3. Design a retry contract for creating a shipment label after a lost reply.

The next chapter asks what an await must remember while the operation is unsettled.

References

1. “Amazon EC2 Developer Guide, “Ensuring idempotency in Amazon EC2 API requests”.” — receiver-recognized client tokens and mismatch handling.
2. “RFC 9110 §9.2.2, “Idempotent Methods”.” — HTTP's precise method-level definition and retry implications.