01
Prompt
Design DoorDash. Three-sided marketplace: eater orders, merchant prepares, Dasher delivers. ~6M orders/day; peak 600 orders/sec; dispatch < 3s.
Time budget: 45 min whiteboard. Draw architecture, estimate numbers, discuss tradeoffs.
Exercise · Marketplace & Booking
DoorDash / Uber Eats
Whiteboard exercise. Try the problem cold, then reveal the rubric to self-score.
02
Hints (progressive — click to reveal)
Hint 1
Three domains: Marketplace (restaurants), Order (saga), Logistics (dispatch). Each owns its own data.
Hint 2
Dispatch is the heart — batched 2-sec window, optimize distance + prep time + batching potential.
Hint 3
ETA is ML with traffic, prep-time, distance; padded for UX asymmetry (2 min early beats 2 min late).
03
Rubric — 10 points
- +1 BoE: 6M orders/day → 70/sec avg, 600/sec peak (Fri dinner); 300K active Dashers; ~10K geo-queries/sec
- +2 Dispatch as 2-sec batched assignment (Hungarian algorithm) over (order, Dasher) scores
- +2 Order lifecycle as saga: payment auth → create order → restaurant accept → dispatch → deliver
- +1 H3 hex cells for geo-index; ring queries for nearby Dashers; Redis hot, Cassandra history
- +1 Three-sided: separate apps + SLAs for eater / merchant / Dasher; merchant POS integration
- +1 ML ETA with traffic, prep-time, historical; padded by 2 min for UX
- +1 Batched multi-order delivery: cut cost per delivery ~30%
- +1 Graceful degrade: ML outage → fallback to nearest-Dasher heuristic; keep orders flowing
Self-score: tally the points you would have mentioned unprompted. 7+ is interview-ready on this problem.
04
Red flags (things that tank the interview)
- Nearest-Dasher-wins greedy (no batching)
- Misses the merchant side entirely
- Tries 2PC across payment + restaurant + dispatch
- One orders table hot-contested across all three parties
- ETA is distance / avg speed (no ML)