Questions: Idempotent Operations in Distributed Systems

Question 1

A payment service receives two HTTP requests with identical idempotency keys — the second is a retry after a network timeout. What should the server do?

• A. Process both requests to ensure the payment completes — network timeouts mean the first may not have succeeded
• B. Reject the second request with an error, forcing the client to generate a new idempotency key before retrying
• C. Recognize the duplicate key, skip the second operation, and return the result of the first successful execution
• D. Block all subsequent requests for that account until the first request's outcome is manually confirmed

Answer: (C)

This is exactly what idempotency keys are designed for. The server stores the outcome of the first successful operation alongside its idempotency key. When the second request arrives with the same key, the server detects the duplicate, skips re-execution, and returns the cached result. The client gets the same response regardless of how many times it retried — the customer is charged exactly once. Options A would charge twice; B defeats the purpose of retrying; D creates unacceptable latency and complexity.

Question 2

An API has two balance endpoints: POST /accounts/{id}/credit with body {amount: 100} and PUT /accounts/{id}/balance with body {balance: 600}. A network fault causes each request to be delivered twice. Which outcome is correct?

• A. Both endpoints charge twice — all POST and PUT requests must be treated as non-idempotent by default
• B. The POST endpoint adds $200 total (non-idempotent: each delivery executes the increment), while the PUT endpoint sets the balance to $600 exactly once (idempotent: repeated sets produce the same result)
• C. The PUT endpoint is non-idempotent because PUT creates a new resource on each call
• D. Both endpoints are safe to retry because modern databases handle duplicate detection automatically

Answer: (B)

This scenario captures the core distinction. 'Add $100' is non-idempotent: applying it twice changes the outcome (adds $200 instead of $100). 'Set balance to $600' is idempotent: applying it twice leaves the balance at $600 — the second application has no additional effect. HTTP PUT is designed to be idempotent (setting a resource to a specific state), while POST for incremental operations typically is not. Idempotency depends on the operation's semantics, not the HTTP method alone.

Question 3

If an operation fails and returns an error response, the client can safely retry it because a failed operation cannot have partially changed server state.

• T. True
• F. False

Answer: False

This is the core problem idempotency solves. In a distributed system, 'failure' is ambiguous: a timeout means the client never received a response, but the server may have already completed the operation successfully before the response was lost in transit. The operation may have fully executed on the server — it is the confirmation that was lost. Retrying a non-idempotent operation in this scenario causes double execution. The client has no way to distinguish 'request never arrived' from 'request completed but response was lost' without additional mechanisms like idempotency keys.

Question 4

HTTP DELETE is designed to be idempotent: sending the same DELETE request multiple times should produce the same server state as sending it once.

• T. True
• F. False

Answer: True

By HTTP specification, DELETE is idempotent: if a resource is deleted, it no longer exists, and deleting a non-existent resource is a no-op (the resource remains gone). The state after one DELETE equals the state after ten DELETEs. This does not mean the server must return the same status code — a first DELETE might return 200, subsequent ones might return 404 — but the state of the system (resource absent) is unchanged by repetition. This is exactly what idempotency means: same effect, not necessarily same response.

Question 5

A developer argues that idempotency is only important for payment systems and financial APIs. Why is this reasoning too narrow?

Model answer: Idempotency is required anywhere messages can be delivered more than once or where retries occur — which is nearly everywhere in distributed systems. Message queues (Kafka, SQS) commonly deliver messages at least once, so consumers must be idempotent. Event-driven systems fire events that may be processed more than once across restarts. Database writes wrapped in retryable transactions must account for partial failures where the write succeeded but the commit confirmation was lost. Any microservice making outbound API calls over a network faces the same problem. The question 'what happens if this runs twice?' should be asked of every operation in a distributed system, not just payments.

The financial example is memorable because the consequences are obvious (double charges), but the distributed systems challenge is universal. A non-idempotent email-sending operation retried after a timeout sends duplicate emails. A non-idempotent inventory decrement retried doubles the deduction. Idempotency is a correctness property for any system where 'at-least-once delivery' is the reliability guarantee — which covers most practical distributed systems.