Design an idempotent order creation API
PremiumAPI designMedium
- Idempotency keys
- Safe retries
- Request fingerprinting
Quick answer
This API design interview question asks you to design an idempotent order creation API. Aim for a design that exposes a clear, consistent and safe interface, then explain the resources, requests, responses and error handling. Interviewers want to see how you name resources, version the interface and handle failure cases.
The problem
Design an idempotent order creation API for a food-delivery platform like DoorDash: a POST /orders that any client can retry safely. Mobile networks drop, partners retry on timeouts and customers tap Pay twice, and today 0.3% of orders are duplicates.
Orders come from the platform's own apps and from 300 partner restaurants that integrate by API, and each duplicate is a refund and an angry restaurant. Any retry of the same logical order must return the same result and never create a second order, and the documentation must say precisely how clients use it.
What must an idempotent order creation API do?
- Create: POST /orders with items, delivery address, payment method and a client-supplied idempotency key creates an order and returns it with status and ID.
- Exact retry: The same key with the same body returns the original response, including the same order ID and the same status code.
How well must it do it?
- Correctness under concurrency: Two identical requests 5 ms apart from two app instances produce one order.
- Retention: A key stays valid for 24 hours; after that the same key starts a new order.
What scale should you design for?
Use these numbers in your estimates.
The scale numbers unlock with this questionUnlock
Key concepts
- Idempotency keys
- Safe retries
- Request fingerprinting
- Concurrency control
- Duplicate orders
- Error semantics
How you’ll practise
- Use cases
- Resources
- Endpoints
- Errors, auth and limits
- Versioning
- Wrap-up
Lala, personalized to you, gives a hint when you ask and reviews your design when you are ready.
What do interviewers look for?
In any API design round.
- Starts from the clients and the use cases
- Names resources and operations consistently
- Defines request and response shapes and status codes
- Covers authentication, rate limits and idempotency
- Plans pagination, filtering and versioning
- Explains how clients learn about and recover from errors
Questions people ask about this interview question
- Which design type is this question?
- It is an API design question. You design an idempotent order creation API and explain your choices the way you would in an interview.
- Is this question asked at entry level?
- It is marked Medium. Entry-level engineers can practise it, but it expects you to reason about requirements and trade-offs, not only list components.
- What should I cover first?
- Start with the clients, the main use cases and the resources they need. Agree on scope with the interviewer before you design anything.
- Can I practise it for free?
- It is a premium question. Sign up and unlock it once for 10 credits; it then stays unlocked. When you finish, Lala, your personalized AI mentor, can review your design for 30 credits.
Related questions
Updated · Written by the SevyDevy team