Design a Food Delivery System

Intermediate · 24 min read · Low-Level Design, Case Studies: Business Systems

Single-restaurant cart, coupons, order state machine, limited stock and partners.

"Design Swiggy/Zomato" in an LLD round is about the order pipeline inside one service: restaurants and menus, a cart with business rules, a price breakdown with coupons, an order state machine with cancellation rules, delivery-partner assignment, and notifications on every status change.

What the interviewer expects

The full design in this lesson is longer than anything you'd write in one round. It's there so you understand the edge cases and can answer follow-up questions. In the round itself, aim for this:

1. Requirements

2. Class design

3. Cart rules live in the cart

The single-restaurant rule is a business invariant, so the cart enforces it — not the controller and not the service. (The apps then ask "start a new cart?", which is a UI decision.)

4. Pricing: strategies and a transparent breakdown

5. Placing an order: reserve limited stock atomically

A limited item (10 thalis a day) is a shared counter that many customers decrement at once — the parking-spot race again. Reserve with compare-and-set, all lines or none:

6. The order state machine

The cancellation policy is the transition table: "customers can't cancel once preparation starts" is simply the absence of PREPARING → CANCELLED. Every cancellation path must also undo side effects — release stock, free the partner, trigger the refund:

7. Delivery partners and notifications

Partner assignment reuses the cab-booking idea: sort free partners by distance to the restaurant and claim the first one with a compare-and-set, falling back to the next if another order won it. Assigning at acceptance (not at placement) means the partner travels while the food cooks.

8. Patterns used

9. Extensions

Interview questions

  • How do you stop an item with limited stock from being oversold?
  • Where do the cancellation rules live?
  • Why store the price breakdown on the order instead of recomputing it?

Further reading

Key takeaways

  • Put invariants where the data is: the cart enforces one restaurant; the order enforces its transitions.
  • Price with strategies and return an itemised breakdown; freeze it on the order.
  • Reserve limited stock atomically, all-or-nothing, and release it on every cancellation path.
  • The transition table is the cancellation policy; every exit undoes side effects.
  • Publish every status change to listeners instead of calling notifiers directly.

Previous: Design a Cab Booking System · Next: Design a Hotel Booking System