Idempotency is the property that repeating an operation produces the same externally relevant result as performing it once. It makes duplicate execution safe, which matters when systems retry failed work or deliberately send duplicate requests. section 10.2.3 section 10.6.2
Safe repetition versus duplicate side effects
Reading a user profile is often idempotent: repeating the read does not change the profile. Processing a payment is not automatically idempotent because repeating it might charge the customer twice. A payment system therefore needs retry behavior that cannot turn a failed transaction into a duplicate charge. section 10.2.3 section 10.6.2
Idempotency simplifies asynchronous recovery. Retry mechanisms commonly use exponential backoff for transient failures, while idempotent operations make each retry safe despite nondeterministic execution order. Synchronization can use unique operation identifiers such as hybrid logical timestamps or vector clocks, repeatable state transitions such as CRDTs, or conditional updates. section 10.6.2 section 11.3.4
Request hedging depends on idempotency: a client sends duplicate requests and keeps the first response, trading additional service load and more complex error handling for lower tail latency. The trade-off is appropriate only when the latency benefit justifies those costs. section 10.2.3
Figure 10.3 Request hedging is a latency-hiding technique where the client sends two or more copies of the same request and uses the first response that arrives, ignoring any responses that arrive later for whatever reason. For example, perhaps the network path for some of the requests and responses is slower than for others, or the messages got queued somewhere along the path.
Visualizes duplicate requests racing through variable network and queueing paths, clarifying why hedging requires safely repeatable operations. section 10.2.3
