Design coffee-shop ordering with menu snapshots, order states, idempotent payment coordination, preparation queues, and recovery from partial failures.
Design an order-management system for a coffee shop. Explain how an order is placed, priced, accepted, prepared, and marked ready, and how the design handles retries and changes during preparation.
### Constraints
The number of stores, ordering channels, payment integration, and throughput are unspecified. Establish a baseline before scaling the design. Any assumptions about menu customization, cancellation, inventory, or payment timing must be stated explicitly.
### Clarifying Questions
- Does the system serve one shop or many, and are orders placed at a counter, online, or both?
- Which drink options and prices must be captured at order time?
- At what point can an order be changed or canceled?
- What guarantees do staff need about order sequencing and readiness updates?
```hint Make the order's lifecycle explicit
A retry should not create a second drink order or charge merely because the first response was lost.
```
### What a Strong Answer Covers
- Menu and order representation, price snapshots, and a clear state machine.
- Idempotent creation, payment coordination, and staff-facing work queues.
- Concurrent updates, failure recovery, and operational visibility.
### Follow-up Questions
- How would a temporarily disconnected preparation screen catch up?
- What happens if payment succeeds but order acceptance is not recorded?
Overview: Design coffee-shop ordering with menu snapshots, order states, idempotent payment coordination, preparation queues, and recovery from partial failures.
Design an order-management system for a coffee shop. Explain how an order is placed, priced, accepted, prepared, and marked ready, and how the design handles retries and changes during preparation.
Constraints
The number of stores, ordering channels, payment integration, and throughput are unspecified. Establish a baseline before scaling the design. Any assumptions about menu customization, cancellation, inventory, or payment timing must be stated explicitly.
Clarifying Questions Guidance
Does the system serve one shop or many, and are orders placed at a counter, online, or both?
Which drink options and prices must be captured at order time?
At what point can an order be changed or canceled?
What guarantees do staff need about order sequencing and readiness updates?
What a Strong Answer Covers Guidance
Menu and order representation, price snapshots, and a clear state machine.
Idempotent creation, payment coordination, and staff-facing work queues.
Concurrent updates, failure recovery, and operational visibility.
Follow-up Questions Guidance
How would a temporarily disconnected preparation screen catch up?
What happens if payment succeeds but order acceptance is not recorded?