Geo search & delivery dispatch

Design Zomato

Hard

Find the open restaurants around a hungry user in 200 ms, then dispatch the best rider from thousands of moving dots — before the food goes cold.

Zomato is a food-delivery marketplace with three sides that must meet in real time: eaters searching for something nearby, restaurants cooking the food, and delivery partners (riders) ferrying it across a live city.

Two hard problems sit on top of an otherwise ordinary e-commerce checkout:

Geospatial discovery — given a user's exact location, return the open, serviceable restaurants around them, ranked and filtered, in under 200 ms, from hundreds of thousands.
Real-time delivery logistics — the instant an order is ready, pick the right rider from thousands of moving dots, guided by GPS pings arriving tens of thousands per second, and keep the eater's map fresh until the doorbell rings.

Neither side tolerates staleness for long: a restaurant shown "open" that just closed, or a rider dispatched from across town, breaks the experience. The whole design is about indexing a moving world and matching supply to demand under a ticking clock — the canonical geo-search + dispatch interview.

Scope it fast. Split the discovery (read / geo) path from the order + dispatch (write / logistics) path early, and name the two cruxes — geo-search and rider matching. That framing drives every later decision. Keep the functional list to the eater-facing core; restaurant- and rider-app screens are supporting surfaces, not the interview's signal.

Functional

Discover restaurants near me — geo search from the user's location with filters (cuisine, rating, delivery time, open now) and ranking.
Browse a menu and place an order — cart, checkout, payment.The payment gateway itself is treated as a black box here.
Dispatch a delivery partner to each order — assign the best available rider.The rider app streams GPS and accepts/declines offered jobs; one rider serves one active order (or a small batch) at a time — never double-assigned.
Live order tracking — order state (placed → preparing → picked up → delivered) plus the rider's real-time position on a map.

Non-functional

Discovery latency — nearby search < 200 ms p99, out of ~500k restaurants.
Dispatch latency — assign a rider within a few seconds of readiness (< 5 s p95).
Location freshness — the rider's dot on the eater's map is fresh within ~5 s.
Scale — ~40M DAU, ~10M orders/day, ~300k riders online at peak pinging every 4 s (~75k location writes/s).
Availability — discovery/browse 99.9%+; order-taking highly available; the order state machine strongly consistent.
Correctness — an order is never lost or double-charged, and a rider is never assigned to two conflicting orders.

Out of scope

Restaurant-side ops (menu editing, accept/reject console)
Dynamic surge pricing & rider incentives
Fraud / abuse ML and ranking models
In-app chat & customer support
Payment-gateway internals & settlement

Check yourself· 3 questions

Question 1

Which pair of problems makes Zomato harder than a generic e-commerce checkout?

Question 2

Why is this a two-sided (really three-sided) marketplace problem rather than a single-user CRUD app?

Question 3

Which non-functional target most directly forces a specialized geo index instead of a plain SQL WHERE?