Backend Developer interview question
How do you design an idempotent API?
An idempotent write can be retried without creating another business effect. Store an idempotency key with the request result or business identifier and return the original result for a duplicate.
Direct answer
What a strong answer covers
How it works
Clients retry on timeouts without knowing whether the first attempt succeeded, so a write must be safe to repeat. The client sends an idempotency key per logical operation; the server stores the key with the outcome before or within the same transaction as the side effect, then returns the stored response for any later request with that key. Natural keys such as an order number can replace generated keys when the business already has one. GET, PUT, and DELETE are idempotent by definition; POST needs this mechanism.
Example
A payment POST with the same key after a timeout returns the first payment result instead of charging the card twice. The key row is inserted with a unique constraint at the start of processing, so a concurrent duplicate hits the constraint and waits for or reads the first result rather than running the charge again.
Common mistakes
- Storing the key after the side effect so a crash in between still allows a duplicate.
- Scoping keys globally instead of per client, which lets one tenant collide with another.
- Keeping keys forever instead of expiring them after the retry window.
A useful answer structure
Answer from your own work.
Do not memorise a script: use only examples you can explain honestly in follow-up questions.
Open the desktop workspace and rehearse a clear answer in your own words.