Idempotency
An operation is idempotent if calling it multiple times has the same effect as calling it once. In distributed systems, idempotent operations let you retry on network failure without duplicating side effects — a critical property for any API that handles payments, account changes, or external system calls. Without idempotency, a retried request risks double-charging, double-emailing, or corrupted state.
The standard implementation pattern is the idempotency key: a client-supplied unique identifier (often a UUID) that the server uses to recognise duplicates. The first request with key X executes and stores its result; later requests with the same key return the cached result without re-executing. Stripe popularised this pattern for payment APIs; it's now the canonical approach for any retry-safe API. Idempotency is one of the few API design choices that's genuinely hard to retrofit — much easier to bake in from day one.
Long-form posts that explore idempotency in depth — when to use it, common failure modes, how AI helps.
Related terms
- Regression test
A regression test verifies that previously working functionality still works after a code change.
- Integration test
An integration test verifies that multiple components work together correctly — a service hitting a real database, two microservices communicating, a frontend talking to a real API.
- CI/CD pipeline
A CI/CD pipeline is the automated chain of build / test / deploy steps that runs on every code change.