Swiggy System Design Interview: Live Order Tracking

Mentally split Swiggy into four planes that talk through an event backbone (Kafka), because conflating them makes the design hard to follow. Plane 1 is the discovery / read path. A customer opens the app, the client sends a delivery lat/lng, and the Serviceability service answers 'which restaurants can reach you.' This is a point-in-polygon problem: cities are carved into delivery zones (polygons), and doing a raw PIP check against thousands of polygons per request would be too slow, so Swiggy builds a GeoHash index where each polygon is registered against the GeoHash cells it overlaps. At request time you compute the customer's GeoHash key, fetch the small candidate set of overlapping zones from memory, run the precise PIP only on those, and return the eligible restaurants. The catalog (menus, prices, ratings) is served from a search/listing store (think ElasticSearch + a heavy read cache) because this path runs at 50K-100K reads/s and must stay under 100 ms. Plane 2 is order placement and the state machine. The customer places an order; an Order service writes the order durably (Aurora/Postgres-class transactional store, sharded by city), captures payment idempotently, and emits an order.placed event. The restaurant's partner tablet, connected over a push channel, receives the order and accepts or rejects. Every transition (placed -> confirmed -> preparing -> ready -> picked_up -> on_the_way -> delivered, plus rejected/canceled/refunded branches) is a guarded finite-state-machine step persisted atomically, with each change appended to an order_events log for audit. This is the strongly-consistent core; it cannot be eventually consistent or you get double charges and lost orders. Plane 3 is dispatch, the hardest and most interesting part. Assignment does NOT fire greedily the instant an order is placed. The system waits until the order is close to ready (so the partner arrives just as the food is, minimizing both customer wait and partner idle time), pools the orders that are ready-to-assign in a city zone with the partners available nearby, and solves a Mixed-Integer Program every few seconds: a cost matrix of (partner x batch) where the objective minimizes total wait/cost across the zone, subject to capacity (a partner's bag/load limit), uniqueness (one batch to exactly one partner), and time windows (arrive after food is ready, before it gets cold). Batching, combining two orders from one restaurant going to nearby drops, or two nearby restaurants to nearby drops, is what makes peak economics work; it is a small Vehicle Routing Problem inside each batch. The ETA shown to the customer comes from a separate ML model (Swiggy's is a multi-output network that jointly predicts assignment delay, first-mile, kitchen wait, and last-mile). Plane 4 is live tracking. Once a partner is on a trip, their app pings location every few seconds into an in-memory geo store; a tracking service streams that to the customer app over WebSocket/push and recomputes ETA. Pings are never written at full fidelity to the order DB, they live in Redis-class memory and a downsampled trace goes to the data lake for analytics. Across all four planes, Kafka carries the events (order placed, accepted, assigned, picked up, delivered) that fan out to notifications, surge computation, analytics, and the partner-payout pipeline. In a real interview, sketch this on the whiteboard before diving into any single box.

In a real interview, sketch this on the whiteboard before diving into any single box.