Handbooks / System Design Case Studies / Chapter 12

Design a Food Delivery App like Zomato

11 pages · ~16 min✓ Reviewed

Builds on Design a Payment System. Next up: Design a Ride-Hailing App like Uber.

System Design Case StudiesPage 1

Problem, Scope and Requirements (Food Delivery App)

1. Scope and Features

Customer app

browse, order, pay

track, rate

Restaurant app

accept orders

menu and stock

Delivery-partner app

accept offers

share GPS

Functional flow of one order

1Search
2Menu
3Cart
4Order
5Pay
6Assign partner
7Track
8Notify
9Rate

Out of scope: grocery delivery

System Design Case StudiesPage 2

High-Level Architecture (Food Delivery App)

1. Edge and Core Services

CDN: serves images and menus close to the user
API gateway: auth, rate limit and routing to services
Clients never call a core service directly

Appscustomer, restaurant, partner
CDNimages, menus
API gatewayauth, rate limit, routing
8 core servicesbehind the gateway

System Design Case StudiesPage 3

Restaurant Search and Discovery (Food Delivery App)

1. Responsibilities and Design

Find open, deliverable restaurants and dishes near the user
Rank by relevance, ETA, rating and offers
One Elasticsearch index, sharded by a city-region geo cell
Query = geo_distance filter + text match + ranking score
Shard by city-region so a 5-8 km query hits one shard

System Design Case StudiesPage 4

Menu and Cart (Food Delivery App)

1. What the Service Owns

Serve menus: read-heavy, about 100:1 reads to writes
Peak figures: about 7,000 menu reads/s vs 70 writes/s
Track item availability and current prices
One cart per user, bound to one restaurant
Cart holds intent only; the price is never final until checkout

2. Design and Caching

Restaurant appstock flag, price
Catalog DBPostgres / MongoDB
Redis60s TTL
CDN60s TTL
Customer appmenu screen

System Design Case StudiesPage 5

Order Service and State Machine (Food Delivery App)

1. Responsibilities and States

Be the single source of truth for order status
Validate every transition; reject illegal jumps
Emit an event on each change (Kafka)
Side exits: CANCELLED, REJECTED, REFUNDED
Other services react to events, they never write orders

CREATEDorder saved
PAYMENT_PENDINGawaiting PSP
PAIDwebhook ok
RESTAURANT_ACCEPTEDwithin 3 min
PREPARINGkitchen
READYpacked
PICKED_UPpartner has it
DELIVEREDterminal

System Design Case StudiesPage 6

Payments (Food Delivery App)

1. Responsibilities and Design

Charge once: no double charge, ever
Methods: UPI, cards, wallet, COD
COD: collected at delivery, no PSP charge
Also owns refunds and restaurant settlements

Order Serviceasks to charge
Payment Serviceone PSP interface
Razorpayprimary PSP
Paytmfallback on gateway error

System Design Case StudiesPage 7

Delivery Partner Assignment (Food Delivery App)

1. Goal and Candidate Matching

Goal: pickup time = food-ready time for every order
Minimise partner idle wait at the restaurant and total delivery time
Locations live in Redis GEO or an in-memory H3 cell index
Candidates: status AVAILABLE within 3 km, expand to 5 km
Score = distance + load + rating + predicted prep time

Score factor

System Design Case StudiesPage 8

Live Order Tracking (Food Delivery App)

1. Responsibilities and Ingest

Ingest partner GPS from the delivery app
Show a live map + ETA to the customer
Keep trip history per order (track points)

Input	Estimate
Ping interval	every 5 s per partner
Transport	MQTT, or HTTP batch of several points

System Design Case StudiesPage 9

Notifications (Food Delivery App)

1. Responsibilities and Design

Tell the customer, restaurant and delivery partner about each order event
Channels: push, SMS, in-app, email
Transactional (order updates, OTP) always beats promotional: it never waits behind promos

Kafka consumersorder events
Template + preferencerender, opt-outs
Channel workersone pool per channel
FCM / APNs / SMS / emailexternal providers

System Design Case StudiesPage 10

Scaling, Failure Handling and Interview Questions (Food Delivery App)

1. Peak Hours and Sharding

Lunch/dinner is 3x: 230 orders/s avg → 700 orders/s peak, 7,000 search/menu reads/s
Spikes are predictable, so pre-scale autoscaling groups on a schedule, not on CPU alone
Shed non-critical load first: recommendations, promos. Never shed order or payment paths
Rate-limit per user at the API gateway so one client cannot eat the peak

Data	Shard key

System Design Case StudiesPage 11

Check yourself

A customer taps Pay, the network times out, and they tap Pay again. The client sends POST /orders twice. What stops a double charge, and where does it hold?

Both requests carry the same Idempotency-Key, so Order Service returns the same order for the second call instead of creating another.
The payments row also stores an idempotency_key, so the PSP is asked to charge only once.
If the PSP webhook arrives twice, the duplicate is dropped by matching psp_ref.
One check is not enough. The key has to be enforced at order creation, at the charge and at the webhook.

An order is PAID at version 5. The restaurant's Accept and the 3-minute auto-cancel timer both read version 5 and run their UPDATE at the same moment. What happens?

Metric	Math	Estimate
Orders per day	given	20M
Average orders	20M / 86,400 s	230 orders/s
Peak orders	3x at lunch and dinner	700 orders/s
Peak browse reads	10x browse-to-order	7,000 search/menu reads/s
Partner location writes	500K partners / 5 s ping	100K writes/s

Requirement	Target	Applies to
Search latency	p99 < 200 ms	Restaurant and dish search
Order placement latency	p99 < 500 ms	Checkout to confirmed order
Availability	99.95% (about 4.4 h downtime/year)	Whole platform
Double charge	never	Payments
Lost order	never	Orders

	Sync REST/gRPC	Async Kafka
Used for	reads and checkout	everything downstream
Caller waits?	yes	no
Examples	menu read, create order	`OrderPlaced`, `OrderAccepted`, `PartnerAssigned`

Store	Holds	Why
Postgres	orders, payments	transactions, strong consistency
Elasticsearch	search index	text + geo queries
Redis	cart, geo	fast, in-memory
Cassandra	location history	heavy append-only writes

S2 level 5-6	about 150-300 km	Shard key
Geohash precision 3	about 150 km	Shard key (alternative)
Geohash precision 5-6	about 5 km / 1 km	Too small to shard; fine for cache keys

Metric	Why it matters
Zero-result rate	Coverage or query-parsing gaps
Search-to-cart conversion	Result quality
p99 latency	Target under 200 ms
Index lag	Target under 5 s

Entity	Fields
Menu	`restaurantId`, `category`, item list
Menu item	`id`, `price_paise`, `veg`, `available`, `variants[]`, `addons[]`
Cart	`restaurantId`, `lines[{itemId, qty, addons}]`

Metric	Target
Menu cache hit rate	above 95%
Cart-to-checkout rate	watch for drops
Price-mismatch count	low and stable

Table	Holds
`orders`	id, user_id, restaurant_id, status, `version`, total_paise, address, created_at
`order_items`	one row per line item of an order
`order_events`	append-only audit log of every transition
Shard key	`order_id`

Endpoint	Notes
`POST /orders`	needs `Idempotency-Key` header
`GET /orders/{id}`	current status
`POST /orders/{id}/cancel`	allowed only from early states

Failure	Handling
Webhook lost or delayed	Reconciler polls the PSP for payments pending over 5 min
Charge succeeded but order creation failed	Refund automatically
PSP timeout on charge	Query that PSP by `psp_ref` first, then fall back
Duplicate webhook	Dedupe on `psp_ref`

Distance to restaurant	Closer partner ranks higher
Current load	Fewer active orders ranks higher
Rating	Higher rating ranks higher
Predicted prep time	Partner arrives when food is ready

Failure	Response
No partner found	Widen radius, add an incentive, then notify the user of delay
Partner offline mid-order	Reassign the order to the next-best partner

Failure	Handling
GPS gap / tunnel	interpolate; show last-known marker
WebSocket drop	client polls `GET /orders/{id}/track`
Partner stops pinging	Redis TTL 30s expires the hash

Problem	Response
FCM throttling or outage	Retry with exponential backoff, then dead-letter queue
Stale device token	`404` from provider: prune the row
Promo spike	Separate queues, transactional never blocked
Metrics	Delivery rate, send latency < 2s p99, opt-out rate

Orders (Postgres)	`order_id`	Even spread, every order read is by id
Search (Elasticsearch)	city-region geo cell	A 5-8 km query hits one shard
Track points (Cassandra)	`order_id`	One trip's points in one partition
Whole stack	city = cell	One city outage never spreads

Data	Choice	Cost and fallback
Search	AP, eventually consistent	Index lag under 5s; re-check availability at cart time
Orders, payments	CP, strongly consistent	Rejects writes during a partition rather than risk a wrong charge
Cart (Redis)	Fast but volatile	If lost, rebuild from the client cart

Design a Food Delivery App like Zomato

1. Scope and Features

1. Edge and Core Services

1. Responsibilities and Design

1. What the Service Owns

2. Design and Caching

1. Responsibilities and States

1. Responsibilities and Design

1. Goal and Candidate Matching

1. Responsibilities and Ingest

1. Responsibilities and Design

1. Peak Hours and Sharding

2. Scale and Traffic

3. Non-Functional Targets

2. Sync vs Async Communication

3. Storage and Ownership

2. Query Flow

3. Data Model and API

4. Failures and Metrics

3. Data Model and APIs

4. Failures and Metrics

2. Guarded Transitions

3. Data Model and API

4. Failures and Metrics

2. Payment Flow

3. Data Model

4. Failures and Metrics

2. Offer Flow

3. Data Model and API

4. Failures and Metrics

2. Design

3. Data Model

4. Failures and Metrics

2. Event Flow

3. Data Model and API

4. Failures and Metrics

2. Consistency Trade-offs

3. Failure Handling

4. Interview Checks