Idempotency
Make retries safe, so a request sent twice (because of a timeout) has the same effect as sending it once.
Retries are inevitable
Networks lose responses. When a client times out, it can't tell whether the server never got the request or did the work and the reply got lost. The only safe move is to retry, which is dangerous if the operation charges money, sends a message or creates an order.
An operation is idempotent if doing it twice has the same effect as doing it once. GET,PUT (set to a value) and DELETE are naturally idempotent; "add ₹500" or "create an order" are not, unless you make them so.
Try it
The first response gets lost and the phone retries. Pay once without an idempotency key, then once with it.
How idempotency keys work
- The client generates a unique key per user action (not per attempt) and sends it with every retry.
- The server stores the key with the result, in the same transaction as the work.
- If the key arrives again, the server returns the saved result instead of doing the work again.
- Keys expire after a while (Stripe keeps them for 24 hours).
The same idea makes message consumers safe under at-least-once delivery: record each processed message ID and skip repeats. See message queues.
In the interview
- Any payment, order or "send" endpoint should take an idempotency key. Say so unprompted.
- Explain where the key is stored and that the check and the work happen atomically.
- Pair it with retries: retries with backoff plus idempotency is how real systems survive flaky networks.