What is Idempotency in System Design?
Learn what idempotency means in system design, why retries need it, and how idempotency keys prevent duplicate charges or orders.
Expected Interview Answer
Idempotency means that performing the same operation multiple times produces the same result as performing it once, so retries or duplicate requests do not cause unintended side effects like double charges or duplicate records.
In distributed systems, network failures make it impossible to always know whether a request succeeded or the response was simply lost, so clients often retry. If the underlying operation is not idempotent, a retried "charge customer" request could bill them twice even though only one charge was intended. APIs achieve idempotency by having clients attach a unique idempotency key to a request, which the server stores alongside the result of the first execution; if the same key arrives again, the server returns the cached result instead of re-executing the operation. HTTP methods like GET, PUT, and DELETE are naturally idempotent by specification, while POST is not, which is why payment and order-creation endpoints commonly require an explicit idempotency key even though they use POST.
- Makes retries safe, even over unreliable networks
- Prevents duplicate side effects like double charges or duplicate orders
- Simplifies client retry logic without risking data corruption
- Improves reliability of distributed workflows and message processing
AI Mentor Explanation
Idempotency is like a scorer who, when told "add four runs for that boundary" using the exact same ball number, checks whether that ball has already been scored before adding anything. If the umpire’s signal gets repeated over the radio due to static, the scorer recognizes the same ball number and does not add four runs twice. But if told simply "add four runs" with no reference to which ball, repeating the message would wrongly inflate the score. That distinction between an operation tied to a unique reference versus a blind repeat is exactly what idempotency guarantees.
Step-by-Step Explanation
Step 1
Client generates a unique idempotency key
Before sending a request, the client creates a unique key (e.g. a UUID) tied to that specific operation attempt.
Step 2
Server checks for an existing result
On receiving the request, the server looks up whether that key has already been processed.
Step 3
Execute once, cache the result
If the key is new, the server performs the operation and stores the result keyed by that idempotency key.
Step 4
Return cached result on retry
If the same key arrives again, the server skips re-execution and returns the previously stored result.
What Interviewer Expects
- Correct definition: repeating the operation has the same effect as doing it once
- Explanation of why retries happen in distributed systems (timeouts, lost responses)
- Concrete mechanism: idempotency keys stored server-side
- Awareness of which HTTP methods are idempotent by specification (GET, PUT, DELETE) vs POST
Common Mistakes
- Confusing idempotency with simply retrying a request without any safeguard
- Claiming all HTTP methods are idempotent by default, including POST
- Not mentioning a mechanism like idempotency keys for achieving it
- Overlooking why idempotency matters specifically for payment or order-creation endpoints
Best Answer (HR Friendly)
“Idempotency means that if the same request gets sent more than once, maybe because of a network hiccup and a retry, the outcome is exactly the same as if it had only been sent once. Systems achieve this by tagging each request with a unique key, so if that key shows up again, the server just returns the original result instead of doing the work twice, which is especially important for things like payments so a customer never gets charged twice for one purchase.”
Code Example
const processedRequests = new Map() // key -> stored result
async function chargeCustomer(req, res) {
const idempotencyKey = req.headers["idempotency-key"]
if (!idempotencyKey) {
return res.status(400).json({ error: "Missing idempotency key" })
}
if (processedRequests.has(idempotencyKey)) {
// Same key seen before: return the original result, do not charge again
return res.status(200).json(processedRequests.get(idempotencyKey))
}
const chargeResult = await paymentProvider.charge(req.body.amount, req.body.cardToken)
processedRequests.set(idempotencyKey, chargeResult)
return res.status(200).json(chargeResult)
}Follow-up Questions
- Which HTTP methods are idempotent by specification and why?
- How would you implement an idempotency key store at scale?
- What is the difference between idempotency and exactly-once delivery?
- How long should an idempotency key’s stored result be retained?
MCQ Practice
1. What does it mean for an operation to be idempotent?
Idempotency guarantees that repeated executions produce the same end result as a single execution.
2. Which HTTP method is idempotent by specification?
PUT is defined as idempotent — sending the same PUT multiple times results in the same resource state.
3. How do APIs commonly make non-idempotent operations like POST safe to retry?
A client-supplied idempotency key lets the server detect and safely handle duplicate retries of the same logical request.
Flash Cards
What is idempotency? — A property where repeating an operation has the same effect as performing it once.
Why does it matter in distributed systems? — Network failures cause retries, and non-idempotent operations could then double-execute unsafely.
How is idempotency commonly implemented? — Via a client-supplied idempotency key that the server checks before re-executing an operation.
Which HTTP methods are idempotent by spec? — GET, PUT, and DELETE — but not POST.