Loading…

The decisions that matter

Write the order, its payment and an outbox row in one transaction before the kitchen hears of it.Nothing paid for is lost; a retry finds the first order.
Give the kitchen a deadline, then cancel and release the money.An offline tablet can’t strand a paid order.
Precompute who delivers to each map cell; keep live flags apart from menus.The busiest read stays off the database.
Match each zone’s orders and partners together, timed to the food.No partner idles at a counter.
Run each city in its own cell, with one fenced dispatcher per zone.One city’s outage stays in that city.

Architecture diagramThe final design at a glance

The order is written with its payment before the kitchen sees it; each later step is a conditional change on the event stream. Each city’s cell runs its own dispatch. Dashed lines are asynchronous.

Diagram as text

Components: Customer app (Client); API gateway (API gateway); Listing (Service); Live flags and menus (Cache); Payments (UPI, cards) (External API); Order service (Service); Orders and outbox (SQL DB); Order events (Queue); Restaurant tablet (Client); Partner app (Client); Partner positions (Cache); Dispatch (one per zone) (Service); ETA (Service); Live updates (Notifications). Connections: Customer app → API gateway (browse, order); API gateway → Listing (what’s open); Listing → Live flags and menus; API gateway → Order service (place); Order service → Payments (UPI, cards) (hold or debit); Order service → Orders and outbox (one write); Orders and outbox → Order events (outbox), asynchronous; Order events → Restaurant tablet (new order), asynchronous; Order events → Dispatch (one per zone) (ready time), asynchronous; Partner app → Partner positions (GPS), asynchronous; Partner positions → Dispatch (one per zone); Dispatch (one per zone) → ETA; Order events → Live updates (status), asynchronous.

Understanding the problem

A food delivery app is a three-sided marketplace: customers order, restaurants cook, and delivery partners carry. The app shows each customer the restaurants that can deliver to them now, takes the order and the payment, hands it to the kitchen, finds a partner, and keeps everyone told until the food arrives.

Confirm these in the first few minutes. Three carry the design: an order that ends delivered or refunded, a partner at the counter when the food is ready, and a promised time that is kept.

Functional requirements

CoreCustomers see restaurants that deliver to their address now, browse menus (dishes with sizes and add-ons), and order and pay by UPI, card, wallet or cash on delivery.
CoreThe restaurant gets the order on its tablet, accepts or rejects it, and marks it ready.
CoreA delivery partner is assigned, collects the order and delivers it; the customer sees the partner on a map and an arrival time.
CoreCustomer, restaurant and partner hear about every step; customers can cancel, and get refunds for missing items.
Below the lineSearch ranking and recommendations.Its own system; the listing only has to be right about who can deliver.
Below the lineRestaurant onboarding and partner payouts.Back-office flows that read the same records.
Below the lineRatings and reviews.
Below the lineGrocery and quick commerce.
Below the lineGrocery and 10-minute delivery.Stock held in dark stores is a different problem.

Non-functional requirements

DurabilityA placed order is never lost or charged twice: it ends delivered, or cancelled and refunded.
ConsistencyEach order has one delivery partner at a time.
Quality9 in 10 orders arrive within the time shown at checkout.
LatencyThe restaurant list loads in under 300 ms (p99), and the partner’s position on the map is at most about 5 seconds old.
AvailabilityAt the peak, the app shows longer times or fewer restaurants rather than taking orders it can’t deliver; one city’s outage never touches another.
Below the line

Scale

From the briefNumbers here are given in the practice brief.

ScaleAbout 500 cities, 300,000 restaurants and 3 million orders a day; most orders are within 7 km.
ScaleThe dinner peak, 8 to 9 pm, runs at about three times the day’s average.
ScaleAbout 400,000 delivery partners, about 150,000 online at the peak, each phone sending its position every 4 seconds.

Out of scope

Out of scopePartner onboarding and KYC.
Out of scopeRestaurant payouts.
Out of scopeAds.

Check yourself

Why is “9 in 10 orders arrive within the time shown” a better target than “arrive on time”?
Show answerHide answer
It can be measured and it admits that some orders run late. It also decides how cautious the promise must be: a time most orders beat, not the average.

The numbers that shape the design

Illustrative exampleNumbers here are illustrative: round figures to reason with, not measurements.

Rounded figures, one line of working each. Orders are few; partner positions and the screens watching them are many.

Back of the envelope for restaurant delivery

Quantity	Value	Working
Orders, day average	About 35 a second	3 million over 86,400 seconds, from the brief.
Orders at the dinner peak	About 100 a second	About 3× the average, from the brief.
Partner positions	About 37,500 a second	150,000 partners online at peak, one every 4 seconds.
Orders per online partner, peak hour	About 2.5	3 million ÷ 24 × 3 ≈ 375,000 in the peak hour, over 150,000 partners; one partner alone manages under two an hour.
Orders in flight at peak	About 200,000	100 a second for about 35 minutes each.
Map updates to customers	At most about 50,000 a second	One every 4 seconds per order in flight; only orders with a partner on the way and a customer watching count.
Listing reads at peak	About 2,000 a second	About 20 opens or searches per order placed.

Architecture diagramWhere the load lands

Diagram as text

Components: Orders at the dinner peak (Client); Order service (Service); Browsing at the peak (Client); Listing (Service); Partners online (Client); Partner positions (Cache); Customers watching (Client); Live updates (Notifications). Connections: Orders at the dinner peak → Order service (~100 a second); Browsing at the peak → Listing (~2,000 a second); Partners online → Partner positions (~37,500 a second); Customers watching → Live updates (≤ 50,000 a second).

Try it: The numbers that shape itGuided practice · Food delivery, Food delivery · Mid-level

Check yourself

Which number says partner positions don’t belong in the order database?
Show answerHide answer
About 37,500 position writes a second against a few hundred order writes: dozens of times the load, each useful for seconds.

Core entities

Illustrative exampleNumbers here are illustrative: round figures to reason with, not measurements.

An order only moves forward, and it copies what was bought (items, add-ons and prices at checkout), so a later menu edit doesn’t change it. Partner positions are not records: just the latest point per partner, ignored once it is about 30 seconds old.

The entities and their key fields

Entity	Key fields	Why it exists
Order	`order_id`, `client_order_id`, customer, restaurant, lines (copied), total, status, `promised_by`	Followed until delivered or refunded.
Payment	order, method (UPI, card, wallet, cash), amount, status; refunds as their own records	Every rupee in or out is a record.
Restaurant	id, location, delivery area, hours; live flags kept elsewhere	Who can cook and deliver where.
Menu	restaurant, version, items with variants and add-ons	Published by version.
Delivery	order, partner, offered, accepted, picked up and delivered times	One committed partner per order.
Partner position	partner, latitude, longitude, last seen; skipped after about 30 seconds	Read by dispatch and the map.

Read:Learn: Data model design Learn: Redis

Try it: Menus, orders and partnersGuided practice · Food delivery, Food delivery · Mid-level

Check yourself

The restaurant raises the price of a dish while an order with it is being cooked. What does the order show?
Show answerHide answer
The price at checkout: the order copied its lines, so the menu’s new version affects only new orders.

The API

Three apps talk to the system: the customer’s, the restaurant’s tablet and the partner’s. The order carries an id the app made, so a retry returns the order already placed. Changes are pushed over a held connection, and every app can fetch the current state after a reconnect.

The main calls

Call	Request	Reply
Place order	`client_order_id`, restaurant, lines, address, payment method	The order with its status and promised time
Get order	The order id	Its current status, partner and promised time
Accept or reject (tablet)	The order id, prep time if known	The order’s new state, or “already cancelled”
Mark ready (tablet)	The order id	The order’s new state
Accept offer (partner)	The offer id	The delivery, or “offer expired”
Status updates	A held connection per app	Pushed changes, each with the order’s version

Architecture diagramAn order only moves forward

Each arrow applies only if the order is still in the state it leaves. A missed deadline, a rejection or the customer can cancel before pickup; before the kitchen accepts the money comes back in full, after that per the cancellation policy.

Diagram as text

Components: Placed, payment secured (Component); Accepted (Component); Ready (Component); Picked up (Component); Delivered (Component); Cancelled, money back per policy (Component). Connections: Placed, payment secured → Accepted (kitchen accepts); Accepted → Ready (marked ready); Ready → Picked up (collected); Picked up → Delivered; Placed, payment secured → Cancelled, money back per policy (deadline, reject or customer); Accepted → Cancelled, money back per policy (customer, per policy), asynchronous.

Read:Learn: API contract design Learn: Idempotency and retries

Try it: Ordering, and hearing backGuided practice · Food delivery, Food delivery · Mid-level

Check yourself

The customer’s order request times out and the app retries. What stops a second order?
Show answerHide answer
The retry carries the same client order id, so the server finds the order it already wrote and returns it instead of placing another.

High-level design

Build the design one flow at a time, following the brief: an order reaching a kitchen, then a partner reaching the order. The deep dives then harden each part.

An order, from tap to kitchen

The customer’s app sends the order with its own id. The order service secures the payment and writes the order, as “placed”, with an outbox row in the same transaction; a relay publishes the event, and the kitchen service rings the tablet until someone accepts.

Acceptance is when the customer sees “confirmed”. Every later step is the same kind of conditional write, announced on the event stream.

The customer places the order with its own id.
The payment is secured and the order written, with an outbox row.
The kitchen’s tablet rings until accepted.
The customer hears “confirmed”.

Architecture diagramAn order, from tap to kitchen

The order and an outbox row are written in one transaction; the tablet rings until accepted. Dashed lines are asynchronous.

Diagram as text

Components: Customer app (Client); API gateway (API gateway); Order service (Service); Payments (External API); Restaurant tablet (Client); Orders and outbox (SQL DB); Order events (Queue); Kitchen service (Service). Connections: Customer app → API gateway (order + its own id); API gateway → Order service; Order service → Payments (secure the amount); Order service → Orders and outbox (order + outbox, one write); Orders and outbox → Order events (relay), asynchronous; Order events → Kitchen service (new order), asynchronous; Kitchen service → Restaurant tablet (ring until accepted).

Read:Learn: Consistency trade-offs Learn: Event-driven / saga

Try it: An order, from tap to doorstepGuided practice · Food delivery, Food delivery · Mid-level

Check yourself

The order service crashes just after writing the order. Does the kitchen still hear about it?
Show answerHide answer
Yes: the outbox row was written in the same transaction, so the relay publishes the event when it next runs.

A partner, from the road to the doorstep

Partners’ phones send their position every few seconds; an in-memory geo store keeps the latest point and last-seen time for each partner, and skips points older than about 30 seconds. When the kitchen accepts, the order’s predicted ready time goes to its zone’s dispatcher.

The dispatcher matches orders to free partners in short rounds and sends an offer that times out. Once accepted, the customer’s map follows that partner until the drop.

Partners report positions to the location store.
The zone dispatcher matches the order to a partner.
The partner accepts the offer, picks up and delivers.
The customer’s map follows the partner.

Architecture diagramA partner, from the road to the doorstep

Design a food delivery app

The answer in two minutes

Also asked as

What interviewers look for

The decisions that matter

Understanding the problem

Functional requirements

Non-functional requirements

Scale

Out of scope

The numbers that shape the design

Core entities

The API

High-level design

An order, from tap to kitchen

A partner, from the road to the doorstep

Sign in with Google to read the rest

Practise this

The answer in two minutes

Also asked as

What interviewers look for

The decisions that matter

01Understanding the problem

Functional requirements

Non-functional requirements

Scale

Out of scope

02The numbers that shape the design

03Core entities

04The API

05High-level design

An order, from tap to kitchen

A partner, from the road to the doorstep

Sign in with Google to read the rest

12Practise this

Understanding the problem

The numbers that shape the design

Core entities

The API

High-level design

Practise this