Loading system design…
Loading system design...
Design a food delivery platform like Zomato, Swiggy, or DoorDash — a three-sided marketplace connecting customers, restaurants, and delivery riders. The system enables location-based restaurant discovery, menu browsing, ordering, real-time delivery tracking with live rider GPS, intelligent rider dispatch, dynamic ETA estimation, and surge-based pricing.
| Metric | Value |
|---|---|
| Registered users | 200 million |
| Daily active users (DAU) | 15 million |
| Partner restaurants | 500,000 |
| Active delivery riders | 300,000 |
| Orders per day | 3 million |
| Peak orders per minute (dinner rush) | 15,000 |
| Average order value | ₹350 (~$4.20) |
| Rider location updates | 300K riders × 12/min = 3.6 million GPS pings/min |
| Restaurant search queries per day | 200 million |
| Average delivery time | 30 minutes |
| Delivery radius per restaurant | 5–10 km |
Restaurant discovery: users browse nearby restaurants based on location (GPS); filter by cuisine, rating, delivery time, cost, offers, and dietary preferences (veg/non-veg/vegan)
Restaurant menu: display a restaurant's full menu with items, descriptions, prices, images, customisation options (size, toppings, spice level), and availability status
Cart and ordering: users add items to cart from a single restaurant, apply coupons/offers, select delivery address, choose payment method, and place the order
Real-time order tracking: after order placement, track the order through stages — restaurant confirmed → preparing → ready for pickup → rider assigned → picked up → en route → delivered — with live rider location on map
Delivery partner (rider) assignment: match the optimal rider to the order based on proximity to restaurant, current load, and estimated delivery time
ETA estimation: show estimated delivery time before and after order placement; factor in food preparation time, rider travel time, traffic, and weather
Ratings and reviews: users rate restaurant (1–5 stars) and delivery experience separately; write text reviews; restaurants can respond to reviews
Restaurant partner management: restaurants manage their menu (add/update/remove items, update prices, mark items as out-of-stock), operating hours, and accept/reject orders
Search: search for restaurants, cuisines, or specific dishes (e.g., 'butter chicken'); autocomplete suggestions; recent/popular search trending
Promotions and pricing: dynamic delivery fee based on distance/demand; surge pricing during peak hours; restaurant offers (buy 1 get 1, flat ₹100 off); referral credits and loyalty programs
Non-functional requirements define the system qualities critical to your users. Frame them as 'The system should be able to...' statements. These will guide your deep dives later.
Think about CAP theorem trade-offs, scalability limits, latency targets, durability guarantees, security requirements, fault tolerance, and compliance needs.
Frame NFRs for this specific system. 'Low latency search under 100ms' is far more valuable than just 'low latency'.
Add concrete numbers: 'P99 response time < 500ms', '99.9% availability', '10M DAU'. This drives architectural decisions.
Choose the 3-5 most critical NFRs. Every system should be 'scalable', but what makes THIS system's scaling uniquely challenging?
The complete explanation is included with Career and All Access. Compare it with your approach once you’ve worked through the problem.
Your system-design submission history is available after you sign in.
Sign In