Design a Food Delivery Service like DoorDash

• POST /orders with { restaurantId, items, addressId, paymentMethodId, idempotencyKey } returns { orderId, status, estimatedDeliveryAt }.
• GET /orders/:id returns status and courier location.
• POST /orders/:id/cancel.

• orders(order_id, customer_id, restaurant_id, courier_id, status, subtotal, fees, total, ready_at_estimate, created_at, version)
• order_items(order_id, item_id, quantity, unit_price, options_json)
• outbox(event_id, order_id, event_type, payload, published)

About 1,000 order writes per second at peak, each with a handful of state updates, is comfortable for a regionally sharded database. Orders are sharded by region so each market is isolated.

Writing the state change and the outgoing event in one transaction (outbox) guarantees no event is lost or emitted for a rolled-back change. Publishing to Kafka directly after the commit risks losing events when the service crashes between the two writes.

Each market runs a matching cycle every few seconds over its pending orders, solving a small assignment problem (couriers to orders, with possible two-order batches) that minimizes a weighted sum of courier wait, food wait, and lateness. Large cities are split into subregions to keep each problem small.

Delaying dispatch until close to the predicted ready time reduces courier idle time at restaurants, which is the largest waste in the system. The risk is late food when the courier pool is thin, so dispatch starts earlier when supply in the area is low.

• courier_state(courier_id) -> { lat, lng, status, active_order_ids, vehicle, updated_at }

200,000 updates per second are in-memory writes spread across market shards. Updates for couriers on an active delivery are also forwarded to the subscribed customer connection and sampled into a trip history for disputes.

Only the latest position is kept in the hot index; history is written in compressed batches. Persisting every point synchronously would cost far more than the value of that data.

• GET /restaurants?lat=&lng=&cuisine=&q= returns restaurants with estimated delivery time.
• GET /restaurants/:id/menu returns the menu with item availability.
• PATCH /restaurants/:id/items/:itemId lets the restaurant mark an item unavailable.

Browse traffic is served mostly from cache. Item availability changes are pushed as small updates that invalidate only the affected menu.

Menus are cached for a minute, so a customer can occasionally add an item that just sold out. The order service re-validates every item at checkout, which is cheaper than making every menu read strongly consistent.

Discovery requests ask for estimates for dozens of restaurants at once, so predictions are batched and cached per restaurant and zone for a minute.

Learned prep time per restaurant and hour is far more accurate than relying on the restaurant's own estimate, which is usually optimistic. The model is retrained daily so it adapts to changes in kitchen speed.

Authorization is synchronous at checkout; capture and payout recording run asynchronously from order events with idempotency keys derived from the order id.

Authorizing at checkout and capturing at delivery means the customer is only charged for orders that arrive, simplifying refunds for cancellations. The cost is that some authorizations expire on very delayed orders and must be retried.