Zomato System Design Interview: Food Delivery at Scale

Listing and discovery data. It lives in the catalog store and the search index and is heavily cached. The geo_cell and zone_id fields let serviceability narrow the candidate set quickly. The is_online flag flips often, for a busy kitchen, a closed restaurant, or an item that is out of stock.

The serviceability polygons. The polygon is the precise boundary for the point in polygon test. The geo_cells field is the denormalized list of cells the polygon overlaps, used to build the in memory index that avoids scanning every polygon on each request.

The transactional core, sharded by city_id and zone_id. The state field is the current state machine state. It needs strong consistency. It is mostly append only, since mutations are state transitions, each mirrored into order_events.

An immutable audit log of every state transition. It lets you reconstruct exactly who did what and when, which is essential for disputes, refunds, and replaying state if the orders row is ever corrupted.

The mostly static partner profile. The live position is not here. It lives in the in memory geo index. The bag_capacity field feeds the dispatch capacity limit, and is_online and current_zone_id scope the assignment candidate pool.

In memory only, in Redis or a custom geo service, keyed by geo cell so proximity queries are cheap. It is overwritten every few seconds. A downsampled trace of completed trips is logged to the data lake, while idle pings expire.

The output of the dispatch engine. A batch can hold more than one order, which is the batching case. The status field tracks accepted, picked up, completed and reassigned. A cancel or an unreachable partner creates a new assignment row and puts the order back into the next round.

Strongly consistent. Indexed by order_id and idempotency_key so a retried capture never double charges. UPI is the dominant method in India, while cash on delivery skips the pre capture and reconciles on delivery. Provider webhooks update the status asynchronously.

Geospatial cell index versus raw point in polygon versus PostGIS

Raw point in polygon against every zone is the simplest option but it is order of the number of zones per request and too slow at tens of thousands of reads per second. PostGIS with a spatial index works but adds load on the busiest read path. An in memory geo cell index, where you precompute which cells each polygon overlaps, look up by cell, and then run point in polygon only on the few candidates, keeps the request in memory and near 100 ms. The cost is that you have to rebuild the index when zones change and pick a cell resolution that balances candidate set size against memory.

Just in time delayed assignment versus assign on order placed

Assigning right away is simpler and feels faster, but it pins a partner idle at the restaurant for the whole preparation time, which is very costly when supply is the peak bottleneck. Delaying assignment until the order is near ready, driven by the predicted preparation time, keeps partners productive but risks under supply if the prediction is wrong and no partner is free when the food is ready. The delayed approach wins because partner idle time is the dominant cost lever at peak, and you reduce the risk by widening the candidate pool as readiness approaches and by pre positioning idle supply with Active Dispatch.

Reinforcement learning Active Dispatch versus static heuristics for supply positioning

A rule based heuristic, such as send idle partners to the nearest busy hub, is easy to build and explain, but it reacts to current demand rather than anticipating it and does not learn from outcomes. Zomato's deep Q network reinforcement learning approach learns a positioning policy that anticipates demand and supply gaps and, in their reporting, beats both no recommendation and rule based baselines. The cost is that reinforcement learning systems are harder to build, train, monitor and debug, and they need the machine learning runtime, with a feature store and model serving, to operate in real time. That is worth it only at Zomato's order density.

Decomposed, weather aware ETA versus a single end to end model

One end to end ETA number is the simplest but it is brittle. It cannot explain itself and it mispredicts whenever the kitchen, the roads, or the weather shift. Breaking it into food preparation time, from a bidirectional LSTM, plus a separately modeled delivery leg with dynamic buffers for traffic and weather, is more accurate and easier to debug, and it lets each part improve on its own. The cost is more models to train and serve, plus the whole Weather Union sensor network to build and maintain, which is a large investment that Zomato judged worthwhile because ETA accuracy directly affects conversion and trust.

In memory geo index for live location versus durable writes

Writing every partner's few second location update to the durable order store would overwhelm it, and almost nothing reads historical pings in real time. Keeping live positions only in an in memory geo cell keyed store gives cheap proximity queries and cheap writes, while a downsampled trace goes to the data lake for analytics. The cost is that a node failure loses live positions, but partners re send within seconds so the index heals itself, which is an acceptable trade for the throughput.

Strong consistency on orders and payments versus eventual consistency everywhere

Discovery, listings and tracking tolerate eventual consistency and stale caches without harm. The order state machine and payment capture do not, because eventual consistency there means double charges, lost orders, or an order stuck between states. So you split the system, with eventually consistent, cached, horizontally scaled read planes around a small strongly consistent transactional core that uses sharded SQL, atomic transitions, and idempotency keys. Do not pay for strong consistency where you do not need it, and never skip it on money and order state.

Surge to flatten peak demand versus fixed pricing

Fixed delivery fees are simpler and feel fairer, but during the dinner rush they leave demand unbounded while partner supply is fixed, which produces long delivery times and failed assignments. A smoothed, clamped surge multiplier trims demand at the edges of the peak and pulls more partners online. The cost is customer friction and the risk of a runaway feedback loop, which you reduce by smoothing over a window, capping the multiplier, and locking the price in at order time.