Idempotence: Why Should Repetition Stop Changing the Result?

Idempotence describes an operation whose intended result does not change when the same operation is applied again. Suppose a system sets a document to “archived”. If the network fails to return confirmation, the client may retry. When the first request has already succeeded, the second still leaves the document archived rather than creating another document. That state transition is idempotent.

This does not mean the operation has no side effects. Each request might still create a log entry, use resources or send a notification. Idempotence requires only that the target state we care about remains the same. It also differs from reversibility, which asks whether we can return to an earlier state. Idempotence asks whether repeating one action keeps pushing the state further. Commutativity instead compares the result of changing the order of two different operations.

Idempotence matters because messages can be delayed and acknowledgements can be lost. We may not know whether an operation failed or succeeded without replying. When important commands can be retried safely, a system does not need perfect communication to preserve consistency. The principle is not “perform it only once”, but “even if it is performed more than once, the intended result remains one”.