Food delivery platform architecture.
Three sides to coordinate and one deadline that nobody controls: the kitchen. Dispatch quality matters more here than any amount of throughput.
The components
Every row below is read from the graph that produced the diagram above, so the two cannot disagree.
| Component | Tier | Why it is there |
|---|---|---|
| Customer app | Client | Supporting component |
| Courier app | Client | Supporting component |
| Merchant tablet | Client | Supporting component |
| API gateway | Edge | Supporting component |
| Menu service | Application | Supporting component |
| Order service | Application | Supporting component |
| Dispatch | Application | Assigns couriers on prep-time estimates |
| ETA model | Application | Supporting component |
| Live tracking | Application | Supporting component |
| Postgres | Data | Supporting component |
| Redis geo | Data | Supporting component |
| Kafka | Data | Supporting component |
Design decisions worth arguing about
A diagram shows what was chosen. It does not show what it cost, and that is usually the part that matters in a review or an interview.
Dispatch on predicted prep time, not on order time
Sending a courier the moment an order is placed means they wait at the restaurant, which wastes the scarcest resource in the system. Sending them to arrive as the food is ready requires predicting prep time, which is a model that will be wrong. Being wrong early wastes courier time; being wrong late means cold food and a bad review. The asymmetry means the model should be deliberately biased toward arriving slightly early.
Three clients, one order state machine
Customer, courier and merchant each see a different projection of the same order, and each can advance it. Letting each app write its own state fields produces orders in impossible combinations. Keeping one state machine with defined transitions makes the invalid states unrepresentable, at the cost of an extra hop for every update and a service that everyone depends on.
The ETA is a product feature, not a calculation
A precise ETA that is sometimes wrong is worse for satisfaction than a padded one that is usually beaten. That means the number shown to the customer is deliberately not the model's best estimate, which feels wrong to engineers and is well supported by how people actually respond to a late delivery versus an early one.
Batch deliveries improve economics and degrade experience
Assigning two nearby orders to one courier meaningfully improves unit economics and makes at least one customer wait longer. Where that line sits is a business decision the dispatch service has to encode, and encoding it explicitly, with a maximum acceptable detour, is much better than letting it emerge from an optimisation objective nobody reads.
How it changes with scale
Demand is extremely peaked around meal times and highly local, so capacity is a per-city, per-hour problem rather than a global one. Courier supply, not compute, is the binding constraint, which means the highest-value engineering is usually in dispatch quality rather than in throughput.
Where it breaks first
Courier supply shortage during a peak. Orders accumulate faster than they can be assigned, ETAs stretch, customers cancel, and cancellations release food that has already been cooked. The system cannot fix this technically; it can only degrade honestly by widening ETAs and, at the extreme, refusing new orders in an area rather than accepting orders it cannot serve.
Draw this yourself
Open the Diagram tab and describe the system. The agent emits a semantic graph rather than coordinates, so you can edit the components and the layout re-solves instead of drifting.
When the shape is right, Implement in code turns the canvas into a markdown specification, every component, every relationship and the notes, and starts a real turn in the Code tab with it.
Questions about this design
More templates
- URL Shortener System DesignThe canonical read-heavy system: roughly a hundred reads for every write, and a redirect that has to be fast enough that nobody notices it happened.
- Chat Application System DesignLong-lived connections change everything: the hard part is not storing messages, it is knowing which of your servers is holding the socket you need to write to.
- Payment System DesignThe only system on this list where being approximately right is indistinguishable from being wrong, and where the provider, not you, holds the truth.
- RAG Pipeline ArchitectureAlmost every RAG system that disappoints is failing at retrieval, not generation, and the architecture is what decides whether you can tell.