Design the backend for a food-delivery platform (think a popular meal-ordering app) that lets a customer order from a nearby restaurant, has a courier pick the food up and drive it over, and shows everyone a live view of where the order is.

Operating context. Three human parties and one physical hand-off chain: the customer places and pays for a cart, the restaurant accepts and cooks it, a courier is assigned and delivers it. You operate in ~40 metro markets; roughly 3 million orders/day with a sharp 3× dinner peak, so plan for ~120 orders/sec sustained and ~600/sec at the peak. Around 80k couriers are on-shift at peak, each phone pushing a GPS ping every 4-5 seconds (~15k location writes/sec). Reads dominate: every active order's three apps poll or subscribe to status + courier position, so the live-tracking read path is 20-50x the order-write path. Money is real: card auth at checkout, capture on delivery, and refunds when things go wrong.

Out of scope. The restaurant discovery/search and menu-catalog service, dynamic surge pricing and the promo/coupon engine, the courier onboarding/background-check pipeline, and the internal fraud-scoring ML. Assume separate teams own those and expose stable APIs.

What to produce. A high-level architecture covering: the components and the request/event flow across the customer, restaurant, and courier apps; the order state machine and who may drive each transition; how a courier is chosen for a new order (the assignment/dispatch path) and what happens when the first pick declines or times out; how live ETA and courier location fan out to all three apps within a few seconds; the data model and its partitioning; how payment auth/capture/refund stay consistent with the order state without blocking the customer; partner (restaurant + courier) availability tracking; and the notification path. Sketch the major components and the flows between them; we will probe specifics during checkpoints.