Premium preview
Design a DoorDash-style food delivery marketplace connecting consumers, Dashers, and merchants.
The requirements are open as a taste. From the numbers onward, the full guide opens in the app.
Do not only state requirements. Ask for them. Each card pairs the design constraint with a clarification question you can say out loud before drawing the architecture.
01An order exists in three apps at once — what keeps the status honest?
One order state machine spans all three parties — placed → accepted → preparing → courier assigned → picked up → delivered — and every transition is an appended event, so customer, restaurant, and courier always read the same truth.
02The moment an order is placed, do we send a courier?
No — dispatch is timed to food readiness: predicted prep time minus courier travel time sets the assignment moment, so the courier and the food arrive at the counter together.
03Can one courier carry two orders at once?
Yes, when pickups are close and prep windows overlap — batching is allowed only while the first order’s extra ride time stays under an explicit detour cap.
04What stops a kitchen from accepting more than it can cook?
Capacity throttling — quoted prep times stretch with live queue depth, and past a cap the restaurant is auto-paused in search instead of silently drowning.
05A menu price changes while the cart is open — who wins at checkout?
The cart is re-validated against the current menu at placement: small deltas re-price with a notice, big ones ask the customer to confirm — and once placed, the price snapshot is frozen.
06A delivery fails — what does the customer get, and who pays for it?
A live-tracked order can be cancelled or refunded from any side, and the event log attributes the failure — restaurant, courier, or platform — so the refund comes out of the pocket that caused it.
Out of scopeRestaurant POS and menu-editing tools (we consume the menu feed, we do not build the editor) · Courier onboarding, background checks, and payroll · Card processing internals (we record who owes what; the processor moves the money)
01A courier taps "picked up" twice on flaky mobile data — what happens?
Nothing extra happens: event ids dedupe retries, while an expected order version plus a legal-transition guard rejects stale or out-of-order state changes so an order cannot double-advance or move backward.
02Friday night melts one metro — does the next city feel it?
No: dispatch, supply/demand, and tracking are partitioned by geographic cell (H3-style hexes), so both load and failure stay local to a region.
03Do courier GPS pings go through the order database?
Never: order writes are transactional and modest; location pings ride a separate high-throughput ingest and push tier, and the two paths share no storage.
04How honest do the ETAs have to be?
Calibrated with a slight pessimistic bias: a promised 35 that arrives in 30 delights, a promised 25 that arrives in 35 becomes a refund — and dispatch itself consumes these numbers, so ETA error is a dispatch bug, not just a UX bug.
05What load do we actually size for?
The Friday dinner peak, roughly 3× the daily average rate — a marketplace that works at 3 pm and collapses at 7 pm does not work.
Real interviews probe far more than a tidy list. These are the scope questions that separate candidates who interrogate the problem from those who recite it.
Numbers, architecture diagram, API and data model, deep dives, expected topics, self-check, whiteboard starter, and common mistakes unlock inside the app.
Locked in the app
Locked in the app
Locked in the app
Locked in the app