Idempotency key storage and concurrency
Design the idempotency layer for a public payments API that handles ~50M write requests/day. Clients pass an `Idempotency-Key` header on POSTs; the same key with the same body must return the original response, and the same key with a different body must be rejected. Keys expire after 24h. Cover the storage, the concurrency control when two requests with the same key arrive simultaneously, and how you keep the recorded response consistent with the side effect that was actually performed.
What a strong answer looks like
Clarify scale and constraints first. Propose a clean component breakdown, then go deep on the hard parts (data model, bottlenecks, consistency, failure modes) and name the trade-offs you are making.
Clarify4:30 left
Estimate4:30 planned
Design13:30 planned
Deep dive10:30 planned
Failure7:00 planned
Which questions mattered is sealed until you submit. Telling you now would just be handing over the edge cases.
Run or narrate your approach, then ask the coach.