Food Delivery System – System Design Interview Preparation

Practice designing a food delivery platform like Swiggy/DoorDash. Cover restaurant discovery, order management, driver matching, and real-time tracking.

This is a full mock interview round, not a written solution to read through. The AI interviewer poses the Food Delivery design problem, pushes back on your choices, and asks the follow-up questions a real interviewer would: how the system behaves as traffic grows, where the bottlenecks move, which consistency guarantees you are trading away, and what happens when a component fails. You get structured feedback and a score on requirement gathering, high level architecture, data modelling, scalability and communication at the end of every attempt.

Designing Food Delivery is a recurring question in High Level Design (HLD) rounds at Google, Amazon, Meta, Microsoft, Netflix and Uber, and at high-growth product companies hiring SDE-2 and above. Working through it out loud - repeatedly, under time pressure - is what separates candidates who know the components from candidates who can defend a design.

What this question is really testing

A three-sided system where the hard part is not any one service but the order state machine surviving a failure from any of the three parties.

Scale to establish before drawing anything

10M daily orders, heavily concentrated in two-hour lunch and dinner windows - peak is several times the average.
Hundreds of thousands of riders sending locations continuously, which is a separate write load from orders.
Restaurant menus change constantly and are read on every search, so they are cache-first.

Core components

Search and discovery – Restaurants by location, cuisine and open status. Geospatial plus a text index.
Order service – Owns the order state machine and is the only writer to it.
Restaurant dispatch – Pushes orders to the restaurant and handles acceptance and rejection with a timeout.
Rider assignment – Proximity plus current load plus estimated prep time. Assigned at acceptance, not at placement.
Tracking service – Rider location streamed to the customer during an active delivery only.

Trade-offs to defend

Assign the rider at placement or at acceptance – Early assignment gets the rider moving sooner and wastes trips when restaurants reject. Late assignment is safer and slower.
Batching deliveries – Two orders on one rider cuts cost and adds latency for whoever is dropped second. It is a product decision expressed in the assignment strategy.
Menu and price freshness – Caching menus is necessary and means an order can be placed against a stale price. Decide who absorbs that.

Follow-up questions to expect

The restaurant rejects an order a rider is already en route to. What happens to the rider, the customer and the payment?
No rider accepts within two minutes. Widen the radius, raise the incentive, or cancel - and whose decision is it?
Peak hour is 6x average for two hours a day. How do you size for that without paying for it all day?