Design Swiggy: System Design Interview Guide

Listing/discovery data. Lives in the catalog store + search index, heavily cached. geohash and zone_id let serviceability narrow the candidate set fast. is_online flips frequently (kitchen busy, closed, out of an item).

The serviceability polygons. polygon is the precise boundary used for point-in-polygon; geohash_cells is the denormalized list of cells the polygon overlaps, used to build the in-memory GeoHash index that avoids scanning every polygon per request.

The transactional core. Sharded by city_id / zone_id. state is the current FSM state. Strong consistency required. Append-mostly; mutations are state transitions, each mirrored into order_events.

Immutable audit log of every state transition. Lets you reconstruct exactly who did what when — essential for disputes, refunds, and replaying state if the orders row is ever corrupted.

Static-ish partner profile. Live position is NOT here — it lives in the in-memory geo index. bag_capacity feeds the dispatch capacity constraint. is_online and current_zone_id scope the candidate pool for assignment.

In-memory only (Redis/custom geo service), keyed by geohash so proximity queries are O(small). Overwritten every 4-5 s. A downsampled trace (one point per ~30 s, completed trips only) is logged to the data lake; idle pings are discarded on expiry.

Output of the dispatch optimizer. A batch can hold multiple orders (the batching case). status tracks accepted/picked_up/completed/reassigned. Reassignment (partner cancels / goes unreachable) creates a new assignment row and re-enters the order into the next optimization round.

Strongly consistent. Indexed by order_id and idempotency_key so a retried capture never double-charges. UPI dominates in the Indian market; COD bypasses pre-capture and reconciles on delivery. Provider webhooks update status asynchronously.

GeoHash polygon index vs raw point-in-polygon vs PostGIS

Raw PIP against every zone is simplest but O(zones) per request and too slow at 50K-100K reads/s. PostGIS with a spatial index works but adds DB load on the hottest read path. An in-memory GeoHash index (precompute which cells each polygon overlaps, look up by cell, then PIP only the few candidates) keeps the request in memory and sub-100ms. Cost: you must rebuild the index when zones change and pick a GeoHash resolution that balances candidate-set size against memory. Swiggy chose the in-memory GeoHash approach.

Just-in-time delayed assignment vs assign-on-order-placed

Assigning immediately is simpler and feels faster, but it pins a partner idle at the restaurant for the entire prep time — catastrophic when supply is the peak bottleneck. Delaying assignment until the order is near-ready, driven by predicted prep 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; you mitigate the risk by widening the candidate pool as readiness approaches.

MIP / global optimization per zone vs greedy nearest-partner

Greedy (assign each order to its nearest free partner) is trivial to build and reason about, but it's locally optimal and globally wasteful — across a zone with hundreds of simultaneous orders it leaves batching and total-cost gains unrealized. A Mixed-Integer Program over the (partner x batch) cost matrix finds a near-global optimum every few seconds. Cost: solver complexity, a hard latency budget, and the need to bound problem size per zone. At Swiggy's order density the MIP pays for itself; a tiny new market could start greedy.

Batch orders aggressively vs single-order trips

Batching roughly halves per-order delivery cost and sheds load during peak (fewer trips), which is why it's essential to the economics. But over-batching delays the first order in the batch and degrades freshness and CX. The resolution is to allow batching only when every order in the batch still satisfies its freshness/time-window constraint, and to cap batch size small (2-3). Efficiency is bounded by experience, not maximized blindly.

In-memory geo index for live location vs durable writes

Writing 35K-45K pings/s to the durable order store would crush it and almost nothing reads historical pings in real time. Keeping live positions only in an in-memory GeoHash-keyed store gives cheap proximity queries and cheap writes; a downsampled trace goes to the data lake for analytics. Cost: a node failure loses live positions, but partners re-ping within seconds, so the index self-heals — an acceptable trade for the throughput.

Strong consistency on orders/payments vs eventual everywhere

Discovery, listings, and tracking tolerate eventual consistency and stale caches fine. The order FSM and payment capture cannot — eventual consistency there means double charges, lost orders, or an order stuck between two states. So you split the system: eventually-consistent, cached, horizontally-scaled read planes around a small strongly-consistent transactional core (sharded SQL with atomic transitions and idempotency keys). Don't pay for strong consistency where you don't need it; never skip it on money and order state.

Surge to flatten peak demand vs fixed pricing

Fixed delivery fees are simpler and feel fairer to customers, but during the dinner cliff they leave demand unbounded while partner supply is fixed, producing long ETAs and failed assignments. A smoothed, clamped surge multiplier shaves demand at the peak's edges and pulls more partners online. Cost: customer friction and the risk of a runaway feedback loop, mitigated by smoothing over a window, capping the multiplier, and locking the price in at order time.