An operation is idempotent if applying it many times has the same effect as applying it once. Reading a value or setting a field to a specific value are naturally idempotent, while blindly incrementing a counter is not. The property matters most in distributed systems, where a network failure can leave a client unsure whether its request actually succeeded, so it has no choice but to retry and risk performing the action twice.
The Amazon Builders’ Library article “Making retries safe with idempotent APIs,” by Malcolm Featonby, explains why this matters in practice. Retries are one of the simplest and most effective ways to handle transient failures, but a naive retry of a non-idempotent operation can cause real damage, such as charging a customer twice. Designing operations to be idempotent lets a service promise that each logical request is processed effectively once, even when the client retries it several times.
The common implementation is an idempotency token, sometimes called a client request identifier or client token. The client generates a unique token, includes it with the original request, and reuses the same token on every retry. The service records the token and, when it sees the same token again, returns the response from the first time the request completed instead of performing the work a second time.
This pattern is what makes safe retries possible across the unreliable boundaries of a distributed system. By moving the responsibility for deduplication into the service and its token bookkeeping, clients can retry freely without complex reconciliation logic, and operations such as submitting a payment or creating a resource can be repeated as many times as the network demands without producing duplicate side effects.