Food Delivery — Notes

Functional

• Restaurant search, menu, order.
• Real-time dispatch to drivers; live tracking; ETA.
• Payment, refunds, support.
• Promotions, ratings.
• Restaurant operations (KDS / prep time).

Non-functional

• Order placement p99 < 1 s.
• Live location updates < 3 s lag.
• City-scale matching < 10 s.
• 99.9% availability for ordering.

Capacity

• 100M+ orders/month for one big platform.
• Peak hours: thousands of orders/min per city.
• Active drivers: 100k+ per city.

Schema

• orders(id, customer_id, restaurant_id, items[], status, totals, driver_id, ETAs)
• drivers(id, status, current_loc, vehicle, ratings)
• presence(driver_id, geohash, ts) Redis geo or KV with TTL
• restaurants(id, geo, hours, prep_time)

Trade-offs

• Centralized matcher simpler but capped by single machine; geo-sharded matcher scales but cross-shard handoffs.
• Batching improves driver utilization but harms ETA reliability.
• Surge pricing balances supply/demand but UX/regulatory issues.

Refs

• DoorDash, Uber Eats, Swiggy engineering posts on dispatch + ETA models.
• "Uber: Real-time dispatching" KDD papers.
• ByteByteGo "Design DoorDash / Uber Eats".