Design a Food Delivery System

The ask

An eater picks a kitchen, builds an order and pays. The kitchen cooks, and a courier carries the food.

Three parties watch the same order. The eater tracks it, the kitchen works to a ready time and the courier follows a route.

Menus belong to kitchens and change during the day. An item can sell out while orders are open.

Payment runs through the payment system. The delivery design takes its answer, paid or failed, as an input.

Estimate the scale

Orders reach 10,000,000 a day.

10,000,000 orders / 86,400 seconds = about 116 orders per second on average.

Dinner concentrates the day. The peak runs at 5 times the average.

10,000,000 orders / 86,400 seconds x 5 = about 579 orders per second at the peak.

The service plans for 1,000,000 couriers.

10,000,000 orders / 1,000,000 couriers = 10 orders per courier per day, on average.

API and data

The order operation takes the eater ID, the kitchen ID and the items. It returns an order ID and a first time estimate.

An order record holds the items, the address and the state. It also holds the kitchen, the courier and the promised time.

Order state moves in one direction. The states are placed, confirmed, cooking, picked up and delivered.

A courier update carries a courier ID and a location. A kitchen update carries a new ready time.

A tracking operation returns the order state and the courier's rough position. Only the order's three parties can call it.

High-level design

An order service owns the order from placement to delivery. It is the one writer of order state.

A dispatch service assigns couriers to orders. It reads courier locations from a location store.

Menu reads serve from a cache. Kitchens change menus slowly, and eaters read them constantly.

Status changes fan out as notifications. Each party gets the changes for its own orders only.

Kitchen load is part of the dispatch data. A kitchen's open orders and ready times shape which orders it can take.

How an order flows

The eater places the order, and payment answers first. A failed payment ends the order before the kitchen sees it.

The kitchen confirms and gives a ready time. A kitchen that cannot cook rejects fast, and the eater chooses again.

Dispatch offers the order to a courier near the kitchen. The offer carries the ready time and the drop area.

The courier collects at the ready time and drives to the door. Delivery closes the order and frees the courier.

Deep dive: dispatch

Dispatch balances three clocks. The food must not wait, the courier must not idle and the eater must not wait hungry.

The nearest free courier is not always the best pick. A courier finishing a drop near the kitchen at the ready time can serve better.

Two orders can share one courier when their doors sit close. Grouping lifts courier use and risks cold food for the second door.

Assignment waits for kitchen confirmation. A rejected order never holds a courier.

Deep dive: the dinner peak

The peak brings about 579 orders per second. It lasts a few hours, not the whole day.

Menus and kitchen pages serve from cache, so the peak lands on orders and dispatch. Those two paths scale out on their own.

Kitchens throttle honestly at the peak. A kitchen at its limit stops taking orders instead of cooking late.

Promised times widen at the peak. A true longer estimate keeps trust better than a short false one.

Deep dive: when an order goes wrong

A courier can cancel after accepting. Dispatch reassigns at once, and the kitchen hears the new pickup time.

A phone retry can place the same order twice. The order operation is idempotent, keyed by a placement ID from the eater's app.

A kitchen that closes mid-order cancels with a refund. The design calls the payment system's refund path for that.

Every state change is written before it is announced. A crash cannot show a pickup that the store never recorded.

Evaluation and trade-offs

One writer for order state trades speed for clarity. Disputes about an order always have one record to read.

Grouping orders trades food quality against courier cost. Distance limits on a group keep the trade bounded.

Live tracking costs location writes all evening. The design tracks couriers on orders, not couriers at rest.

The peak sets the size of the system. Building for the average would fail every dinner.

Food delivery in numbers