
π Food Delivery & QSR Β· Flowchart
How orders from dine-in, takeaway and delivery apps flow through a restaurant kitchen display system to the pass and out.
Drawing diagramβ¦
Kitchen flowchart: orders come from the POS (dine-in, takeaway) and aggregator apps into the kitchen display system (KDS), which splits each order into items routed to stations: grill, fryer, cold, drinks. Cooks bump items when done; when all items are ready the order goes to the pass for quality check and packing. Delivery orders wait for the rider, dine-in goes to the table. Orders past the target time turn red on the display.
flowchart TD
A[POS: dine-in, takeaway] --> K[Kitchen Display System]
B[Aggregator apps: delivery] --> K
K --> C{Route items to station}
C --> G[Grill]
C --> F[Fryer]
C --> CO[Cold station]
C --> D[Drinks]
G --> P[Pass: all items ready?]
F --> P
CO --> P
D --> P
P -->|Missing items| C
P -->|Complete| Q[Quality check and pack]
Q --> R{Order type}
R -->|Delivery| S[Handover to rider]
R -->|Dine-in| T[Serve to table]
K -.->|Past target time| L[Highlight red]A 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.
A schema for a food delivery platform: restaurants, menus, items with add-ons, customers, orders, order items and riders.
How a food delivery platform scales for lunch and dinner peaks: pre-scaling, autoscaling services, sharded databases and a surge-protected dispatch.
A cloud kitchen that runs several virtual brands: orders from aggregators, a kitchen display system, inventory and dispatch.