How do idempotency keys work for POST requests?
Assesses fundamental understanding of REST API Design conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
The client generates a unique key per logical operation and sends it in a header, typically Idempotency-Key.
POST /payments
Idempotency-Key: 4d7c2e6a-2b1f-4f9a-9c3d-1a2b3c4d5e6f
{ "amount": 5000, "currency": "USD" }
The server stores the key together with the request fingerprint and the final response (or a "processing" marker). On a retry with the same key it returns the stored response instead of charging again. Use a unique constraint on the key to make concurrent duplicates safe: one request wins and others receive 409 while the first is in flight.
Keys should expire after a sensible window, be scoped per account, and detect mismatched payloads by comparing a hash. This pattern is essential for payments, order creation and any non-idempotent POST that clients or gateways may retry.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.