A customer taps "Place order" and their app times out waiting for your response, so it retries. Meanwhile your first attempt actually succeeded — the order reached the kitchen. Walk me through how you design the order placement API so retries are safe, and then tell me what happens when the deduplication store itself is briefly unavailable.
Show answer guide
What the interviewer is probing
Whether the candidate reaches for idempotency keys as a design principle rather than a buzzword: where the key is generated, what gets stored, the atomicity requirement between "check" and "act", and TTL trade-offs. The second part tests degraded-mode reasoning — do they fail open (risk duplicates) or fail closed (risk lost orders), and can they connect that choice to the business cost of each failure?
Strong answer outline
- Client generates the idempotency key (per logical order attempt, not per HTTP request) so all retries of one intent share a key.
- Server: atomic check-and-set (e.g. unique constraint or conditional write), not read-then-write — the race between two concurrent retries is the classic bug.
- Store the response with the key so retries return the original result, not just a "duplicate" error.
- TTL discussion: too short re-enables duplicates, too long bloats storage; tie it to realistic client retry windows.
- Degraded mode: articulate fail-open vs fail-closed and pick using domain cost — a duplicate food order costs a refund; a dropped one costs a customer. Reasonable answers differ; unreasoned answers don't.
The underlying concept
Exactly-once delivery doesn't exist between distributed parties; what systems actually implement is at-least-once delivery plus idempotent processing, which is indistinguishable from exactly-once from the caller's perspective. The idempotency key turns a side-effecting operation into something safely retryable by giving the server a durable memory of intents it has already honored. Every payment and ordering system you've used is built on this pattern.
Source
Hand-written seed example in the style of DoorDash's platform reliability posts.