Design food delivery (Swiggy / Zomato)

The order is a state machine, and most production bugs come from illegal transitions: a cancel arriving after pickup, or a payment webhook arriving after the customer gave up. Store status and a version on the order row and make every transition a conditional update: UPDATE orders SET status='ACCEPTED', version=version+1 WHERE order_id=? AND status='PLACED'. If zero rows change, the transition was illegal or a duplicate, and you return the current state. Write an outbox row in the same transaction so the event is never lost or published without the commit. Place-order uses an Idempotency-Key unique per customer, so a double tap or a retry on a 2G timeout returns the same order instead of charging twice. Payments are asynchronous: UPI collect or intent flows finish seconds or minutes later. Treat the gateway webhook as one input and a reconciliation poller as another; both apply the same idempotent transition keyed on payment_id. If payment succeeds after the order was auto-cancelled, issue an automatic refund instead of resurrecting the order. Long-running steps (accept timer, refund) fit a durable workflow engine like Temporal, keyed by order_id.

Greedy 'nearest free partner when an order arrives' looks fine on a whiteboard and fails in practice. It gives a partner to the first order even if a later order 30 seconds away would be a far better match, and it ignores food readiness: a partner who arrives 15 minutes before the biryani is ready wastes capacity at peak. Strong designs run dispatch in rounds per geographic zone (for example a city split into H3 resolution-7 zones) every few seconds. Each round takes unassigned orders whose food will be ready soon and available or about-to-be-free partners nearby, builds a cost matrix (predicted travel time to the restaurant, idle wait at the restaurant, delay to the customer's promised time, partner fairness), and solves a min-cost assignment (Hungarian algorithm or a heuristic for large zones). Batching two orders from the same or nearby restaurants going in the same direction on one trip raises throughput by 20-30% at peak, constrained so the first customer's ETA does not slip beyond a threshold. Run one dispatch worker per zone, owned via a lease, so decisions for a zone are not made twice. Partners on a 2-minute-from-done trip are counted as available soon, which is how real systems keep wait times low.

Partners send GPS every ~5 seconds, batched when the network is poor, with client timestamps so late points can be ordered or dropped. The location service is stateless: it validates the point (drops jumps faster than ~120 km/h or with poor accuracy), writes the latest position to Redis with a TTL and updates the partner's H3 cell set when it changes, then appends to a Kafka topic partitioned by partner_id. Dispatch reads Redis; history goes to Cassandra or S3 for pay, disputes and ETA training. For the customer, a tracking gateway holds SSE or WebSocket connections and subscribes to the events for the orders it serves; it pushes status changes immediately and locations at most every few seconds. Only orders in flight are tracked, so ~300-500k viewers is manageable on a few dozen gateway nodes. The app interpolates the marker along the road between points so it does not jump. When the partner is underground or offline, show the last known position and time rather than inventing movement.

The ETA shown before ordering affects conversion and refunds, so it is a modelled number, not a distance divided by speed. Break it into parts: time to accept, food preparation (a model per restaurant using item count, time of day, current queue of orders at that kitchen), partner first mile (travel to the restaurant plus wait), and last mile (routing with live traffic and historical speeds per road segment and hour). Each part has its own model trained on the location trails and order events; the total is calibrated so that, for example, 90% of orders arrive before the promise. Recompute at each stage and push changes to the customer. Restaurant-side signals matter in India: kitchens get slower during IPL match breaks and festivals, and rain cuts partner speed and supply at the same time. Serve the model from a low-latency feature store (Redis) because listing pages need ETA for every restaurant shown, and cache ETA per (restaurant, H3 cell) for ~1 minute.

Greedy assignment is simple and gives the fastest first decision. Batched rounds of a few seconds give much better global matches and allow multi-order trips, at the cost of a small delay and more complex code. Since food is rarely ready in the first minute, the delay is free; choose batched rounds.

The order service owns order state; payment, dispatch and restaurant services own their own data and react to events. This avoids distributed transactions: the order saga moves forward or compensates (refund, reassign) on events. The cost is eventual consistency between views, so support tools must read the order service as the truth.

Tracking is server-to-client only, so SSE over HTTP/2 is simpler and passes proxies well. WebSocket is useful if the same connection carries chat with the partner. Polling every 10 s is an acceptable fallback on poor networks and is easier to cache, but costs more requests.

COD is still common in smaller cities. It removes payment failure from the order path but adds fraud and partner cash-handling risk. Gate COD by customer trust score and order value, and reconcile partner cash balances daily.

Rain raises orders and cuts partner supply at the same time. The system must shed demand gracefully: increase promised ETAs, add a rain surcharge, temporarily shrink serviceable radius per restaurant, and disable far-away restaurants in listings. These controls must be config-driven per zone so ops teams can act in minutes.

A popular outlet can receive hundreds of orders in minutes during a promotion. Its kitchen, not our database, becomes the bottleneck. Track live kitchen load and throttle the restaurant in listings (show 'busy', longer ETA) before orders pile up and get cancelled.

600k pings/s still fits Redis Cluster and Kafka, but avoid per-ping database writes. Reduce frequency adaptively: every 3 s while riding, every 30 s while waiting at a restaurant, and drop points that moved less than a few metres.

Use multiple gateways with health-based routing. Orders stay in PAYMENT_PENDING; webhooks and the reconciliation poller resolve them later. If money is captured after timeout, auto-refund. Never mark an order placed without confirmation from the gateway.

Zone ownership is a lease in etcd or a database; another worker takes over after the lease expires (~10 s). Orders are read from Kafka and current assignment state from the database, so the new owner resumes without double assignment, because assignment is a conditional update on the task row.

If the restaurant does not accept within ~3 minutes, escalate with an automated phone call (IVR), then auto-cancel and refund. Repeated offline periods mark the restaurant temporarily closed in discovery.