Real-Time Kitchen Display for QR Ordering
Replacing manual order-taking with a QR-based flow and a live kitchen display board that keeps front-of-house and kitchen staff in sync during peak-hour rushes — no app download, no guest login.
Instant
Order visibility delay
-60%
Order entry errors
100+
Concurrent table sessions
Problem
During peak hours, servers couldn't keep up with manual order entry and kitchens had no visibility into what was ordered until a paper ticket physically arrived — creating delays, missed items, and order mix-ups under pressure.
Challenges
- Keeping the kitchen display in sync across multiple screens with zero perceptible lag
- Handling order-state transitions safely when multiple staff members update the same order simultaneously
- Designing a table-session model that works without requiring guests to create an account
- Toggling menu-item availability instantly across all active guest sessions when the kitchen is out of an item
Architecture
Each table's QR code encodes a scoped session token, so guests order without authentication while orders stay correctly attributed. Orders move through an explicit state machine (placed → confirmed → preparing → ready → served), and every transition is broadcast over WebSockets to the kitchen display and the guest's order-status view simultaneously, so no screen ever shows stale state.
Guest scans table QR → scoped session created, no login required
Order placed → persisted and broadcast to kitchen display instantly via WebSocket
Kitchen staff advances order state → state machine validates the transition
Update pushed over WebSocket to guest view and all kitchen screens simultaneously
Item availability toggle propagates to every active session in real time
Database Design
Orders, order items, and their state transitions are modeled relationally in MySQL with an append-only status-history table, so every order's full timeline is auditable after the fact — useful for resolving disputes and analyzing kitchen throughput across service periods.
Scalability
The WebSocket layer is horizontally scaled behind a connection-aware load balancer, and kitchen-display state is rehydrated from the database on reconnect so a dropped connection never loses an order. Menu and availability data is cached and invalidated on write to keep read load off the primary database during rush hours.
Outcome
Order-to-kitchen visibility dropped from a physical ticket delay to instant, and order entry errors fell sharply once servers were no longer manually transcribing orders under pressure during peak service.
Tech Stack
Have a similar problem you're trying to architect your way through?