Idempotency

In distributed systems, you cannot assume a request arrives exactly once. Clients retry after timeouts, queues redeliver messages, and workers may crash mid-processing. If the same request runs twice, you can double-charge a customer, decrement inventory twice, or create duplicate records. Idempotency exists to control that duplicate-execution risk at the level of final state.

As cloud systems and message-driven processing became normal, retries and at-least-once delivery stopped being rare edge cases and became baseline assumptions. Users click again, clients retry, and infrastructure resends work. Designs that quietly depend on exact-once delivery break easily in that environment. Idempotency became a core principle because repetition is part of how real systems survive uncertainty.

A request usually carries a unique key, and the handler records whether work for that key has already been applied. If the same request appears again, the system does not perform the side effect again; it either returns the previous result or safely ignores the duplicate. The core idea is that execution count may vary, but the final business effect should remain stable.

Idempotency and Circuit Breaker are often mentioned together around retries, but they operate differently. Idempotency is a property that makes repeated execution safe. Circuit Breaker is a resilience pattern that decides when calls should be blocked to protect the system. One governs duplicate outcomes; the other governs failure propagation.

Idempotency is close to mandatory in payments, order creation, queue consumers, and other flows where duplicate execution can cause financial or data damage. It is especially important once retries, queues, and long-running workflows are part of the platform. Good idempotency design also requires clear thinking about key scope and retention so duplicates are recognized consistently in production.