
🍔 Food Delivery & QSR · Deployment · Pro
How a food delivery platform scales for lunch and dinner peaks: pre-scaling, autoscaling services, sharded databases and a surge-protected dispatch.
Deployment diagrams are part of Pro. Anyone can view this one; generating and editing it needs Pro.
Drawing diagram…
Deployment for peak-hour scaling: traffic enters through CDN and API gateway with rate limiting, services run on Kubernetes with a scheduled pre-scale before lunch and dinner and autoscaling on CPU and Kafka lag. The order service writes to a sharded PostgreSQL (by city), rider GPS locations go to a sharded Redis cluster, the dispatch service batches assignments during surges, and a surge pricing service adjusts delivery fees.
flowchart TB
U[Customers, restaurants, riders] --> CDN[CDN]
CDN --> GW[API Gateway - rate limits]
subgraph K8s[Kubernetes - pre-scaled before 12:00 and 19:00]
ORD[Order Service x N]
DIS[Dispatch Service x N - batches in surges]
SURGE[Surge Pricing]
LOC[Location Ingest x N]
end
GW --> ORD
GW --> LOC
ORD --> KAFKA[Kafka]
KAFKA --> DIS
DIS --> SURGE
ORD --> PG[(PostgreSQL sharded by city)]
LOC --> REDIS[(Redis cluster - rider GPS)]
DIS --> REDIS
HPA[Autoscaler: CPU and Kafka lag] -.-> K8sA Swiggy/Zomato-style food delivery platform: customer, restaurant and rider apps, and the services that match orders, riders and payments.
Everything that happens between a customer tapping Place Order and the food arriving: payment, restaurant acceptance, rider assignment, pickup and delivery.
Every status of a food delivery order, from placed to delivered, including restaurant rejection, no rider and customer cancellation.
How orders from dine-in, takeaway and delivery apps flow through a restaurant kitchen display system to the pass and out.
A schema for a food delivery platform: restaurants, menus, items with add-ons, customers, orders, order items and riders.
A cloud kitchen that runs several virtual brands: orders from aggregators, a kitchen display system, inventory and dispatch.