Design a coffee shop order management system
PremiumLow-level designMedium
- Order state machine
- Idempotency keys
- Payment retries
Quick answer
This low-level design interview question asks you to design a coffee shop order management system. Aim for a design that is modelled as clear classes, interfaces and relationships that can handle new requirements without a rewrite. Interviewers want to see how you name responsibilities, keep classes small and reason about change.
The problem
Design a coffee shop order management system: the order software behind a café chain's counter and mobile app. It prices drinks with sizes and add-ons, sends items to prep stations and tracks each order to pickup. The hard part is an explicit state machine and retries that never create two orders or two charges.
Orders come from the counter tablet and the mobile app. Mobile networks drop and the app retries, and staff double-tap buttons. Each item goes to a station: hot drinks to the espresso bar, cold drinks to the cold bar and food to the food counter. Baristas claim items, and when every item of an order is done the order shows on the pickup screen.
What must a coffee shop order management system do?
- Order state machine: Orders move CREATED → PAYMENT_PENDING → PAID → IN_PREP → READY → PICKED_UP. Any transition not in the table is rejected and changes nothing.
- Idempotent create and pay: createOrder and pay take an idempotency key; a retry with the same key returns the first result and never makes a second order or charge.
How well must it do it?
- No double charge: Under any retry, double-tap or timeout, an order is charged at most once, and only one payment is in flight per order.
- Safe concurrency: Two baristas never claim the same item, and two calls never move one order through the same transition twice.
What scale should you design for?
Use these numbers in your estimates.
The scale numbers unlock with this questionUnlock
Key concepts
- Order state machine
- Idempotency keys
- Payment retries
- Prep station queues
- Pricing with modifiers
- Concurrency control
How you’ll practise
- Requirements
- Core objects
- Class relationships
- Key flows
- Extensibility
- 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 low-level design round.
- Lists the use cases before writing classes
- Gives each class one clear responsibility
- Uses interfaces where behaviour is likely to change
- Applies a design pattern only when it solves a real problem
- Handles edge cases and invalid states explicitly
- Walks through one use case end to end with the model
Questions people ask about this interview question
- Which design type is this question?
- It is a low-level design question. You design a coffee shop order management system 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 use cases and the core entities, then the responsibilities of each one. 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