Food Delivery System – Low Level Design Interview Practice
Practise the Food Delivery System low level design problem the way an LLD round actually runs. You are asked for requirements first, then a class model, and then to extend the design when a new requirement lands part way through – the follow-up that separates a design that was memorised from one that was understood.
The round checks the things interviewers grade: whether your classes carry single responsibilities, whether you reached for a design pattern or reinvented one, whether the design absorbs a new requirement without rewriting what exists, and whether you can explain a trade-off out loud. Feedback covers class modelling, SOLID principles, use of patterns, extensibility and communication.
What this question is really testing
Three parties with independent lifecycles - customer, restaurant, rider - and an order state machine that has to survive any of them failing.
Requirements to establish first
- Search restaurants by location, cuisine and whether they are currently open.
- Build a cart from one restaurant's menu and place an order.
- Route the order to the restaurant for acceptance, then to a rider for pickup.
- Track the order through placed, accepted, preparing, picked up, delivered.
- Assign a rider by proximity and current load, and reassign when one declines.
Core classes
- Restaurant / MenuItem – The catalogue, its availability and its opening hours.
- Order / OrderItem – What was ordered, at what price, and the status it is in.
- OrderState – The machine. Most transitions are one-way and several have timeouts.
- DeliveryPartner – A rider: location, availability, current assignments.
- AssignmentStrategy – Nearest rider, fewest active orders, or batched multi-pickup.
- NotificationService – Pushes state changes to whichever of the three parties cares.
Design patterns that apply
- State – Order lifecycle, where an illegal transition - delivered to preparing - should be impossible rather than merely guarded.
- Strategy – Rider assignment, which is the part of this system that is genuinely tuned in production.
- Observer – One state change fans out to customer, restaurant and rider with different payloads.
Follow-up questions to expect
- The restaurant rejects an accepted order. Where does your state machine go, and what happens to the rider already en route?
- No rider accepts within two minutes. Is that a retry, a widening radius, or a cancel - and whose decision?
- Batch two orders onto one rider. Does your assignment strategy change, or your Order model?
Where candidates lose marks
- One status string with no transition rules, so any state can follow any other.
- Assigning a rider at order placement rather than at restaurant acceptance.
- Prices read live from MenuItem, so an order's total changes after it was placed.