System 12.18 — Food Delivery (HLD)
In one line
E-commerce + live geo tracking + delivery assignment — the order lifecycle with real-time tail.
Think of it like this
The Swiggy/Zomato LLD from Phase 4, but now zoomed out to the whole city: matching thousands of live orders to thousands of delivery partners at once, in real time.
Key ideas
- 01
Services: restaurant/catalog (menu, availability), ordering, payment, dispatch (delivery assignment), tracking, notification.
- 02
Dispatch: runner pool with live positions; assignment score = ETA + load + rating; atomic claim per rider (12.15 trick).
- 03
Order lifecycle with timeouts: every stage has SLA timers (prep 15min → escalate if exceeded).
- 04
Live tracking: driver GPS → Kafka → redis geo → user sees ETA + map — the geo stream from Uber, now per-order.
- 05
Scale: peak meal times 10x average — queue everything non-critical; restaurant availability cached with short TTL.
- 06
Consistency: order state strong-ish (single order service writes); positions eventual; notifications async.
- 07
Failures: driver cancels after pickup → reassignment + refund logic; restaurant rejects → auto-move to next candidate.
- 08
Interview flow: present as commerce + dispatch + tracking; the dispatch atomic claim is the memorable detail.
Code & diagrams
Three live, moving pieces (order, kitchen, delivery partner) all reading and writing one shared state.
Explain without notes
Restaurant confirms a 45-min prep the system promised in 20 — trace the SLA computation and the compensation.
Practice
Design the dispatch scoring formula and the reassignment on driver-cancel-with-food.
Trade-offs
- ↔
Aggressive dispatch = lower delivery time + higher refund risk; balance with promised-time math.
Completion checklist
I can combine order lifecycle + dispatch + live tracking into one coherent design.