Idempotency

Idempotency is the property that makes retries safe: perform the operation once or five times, the outcome is the same as once. In a world of flaky networks and automatic retries, it is the difference between 'the payment went through' and 'the payment went through four times because the confirmation message dropped'.

What It Is

An operation is idempotent if repeating it has no additional effect: setting a value to five is idempotent (set it again, still five); adding five is not (repeat, and it compounds). In distributed systems, idempotency is engineered deliberately: operations carry idempotency keys so servers recognise and safely ignore duplicates; payment APIs accept a request, return a token, and treat retries with the same token as 'already done' rather than 'do it again'. The pattern extends beyond APIs — message consumers that can process the same message twice without harm make queue redelivery safe; deployment processes that converge to a state rather than apply deltas make reruns safe.

Why It Matters to You

This property is the quiet foundation of reliability in systems that retry — which is all modern systems, because networks fail and retrying is automatic. Its absence produces the doubling family of incidents: duplicate orders, double-charged cards, repeated messages — every one a system doing exactly what it was told, twice. The executive angle is contractual as much as architectural: for payment or order flows, idempotency is a requirement to write into specifications and vendor acceptance criteria (retry-safe under network failure), not an optimisation to assume. The test in review: 'what happens if this request arrives twice?' — the answer distinguishes designed systems from lucky ones.

When You'll Meet It

In integration design, payment flows, and incident reviews of anything duplicated. Make it a standing acceptance criterion for anything money-touching.