Restaurant Kitchen Display System with Station Routing

The problem small restaurants have between the counter and the kitchen

In a busy small restaurant, orders travel on paper chits or are shouted across the pass. A waiter writes the order, the grill cook reads the whole chit even though only one item is theirs, the drinks are ready ten minutes before the food, and a lost chit means a table waiting forty minutes. Owners have no idea which dish is slow or which hour is the bottleneck. Nothing is measured, so nothing improves.

What already exists and the gap

• Square KDS runs on off-the-shelf Android devices, but it is tied to the Square POS and payments ecosystem, which is not available in many countries.
• Fresh KDS runs on standard tablets and suits small cafes, with a subscription per screen.
• Toast offers a KDS as part of its restaurant platform, sold mainly to US restaurants with its own hardware.
• There are open source projects such as KitchenAsty on GitHub, which show interest but are general restaurant suites.

The gap is a KDS that works on whatever cheap screens a small restaurant already has, does not require a specific payment provider, handles desi kitchen stations (tandoor, karahi, BBQ) as configuration, and keeps working through flaky Wi-Fi. Most small restaurants in Pakistan, South Asia and elsewhere have no KDS at all.

What you build

Roles: waiter, customer (via table QR), station cook, expo (the person who checks and sends out food) and owner.

Flow: an order is placed from the waiter phone or a table QR. The server splits it into items and publishes each to its station's channel. Cooks see only their items, tap to start and bump when done. The expo screen shows each order's progress and turns green when all items are bumped. The owner sees prep time reports after service.

The technically interesting part

The hard problem is reliable realtime delivery over unreliable networks. Kitchen Wi-Fi is bad, tablets sleep, and a missed ticket is a customer waiting. Build it properly:

• Every event (order created, item started, item bumped) gets a monotonically increasing sequence number per restaurant.
• Screens remember the last sequence they applied. On reconnect they ask for everything after it, so there are no gaps and no duplicates.
• Bumps are idempotent, so a double tap or a retried request does nothing harmful.
• The server is the source of truth; screens are projections that can be rebuilt from the event log.

This is the same catch-up pattern chat systems such as Discord describe for message delivery. Demonstrate it live: pull the network cable on a station screen during a rush simulation, plug it back in, and show that the screen converges.

How to evaluate it

• Delivery latency: median and 95th percentile time from order placed to ticket visible on the station, over at least 1,000 simulated orders. Target under 500 ms on a local network.
• Reliability: a chaos test that disconnects screens randomly during a simulated two-hour service; report missed or duplicated tickets (target zero).
• Load: use k6 to simulate a peak of 20 screens and 5 orders per minute for an hour and report server CPU and memory.
• Field test: run one real lunch service at a cooperative restaurant and compare average ticket time with a baseline you measured on paper the week before.

Suggested plan

1. Weeks 1 to 3: spend two services in a real kitchen watching the pass. Design events and stations.
2. Weeks 4 to 8: menu, orders, event log, and station screens over WebSockets.
3. Weeks 9 to 12: reconnect and catch-up logic, idempotent bumps, tests.
4. Semester 2, weeks 1 to 4: table QR ordering, expo screen, timers.
5. Weeks 5 to 8: reports, load and chaos testing.
6. Weeks 9 to 14: pilot service, iterate, write up.

Path to a product

Your first customer is a busy mid-size restaurant with two or three stations, near campus, whose owner complains about slow orders. Charge a monthly fee per location, not per screen, so owners do not skimp on screens. Later, integrate with the POS systems local restaurants already use through a simple order import API.

Scope warning

Do not build payments, a full POS, inventory, delivery-app integrations or loyalty programmes. Do not build native apps; a web app in kiosk mode on a tablet is enough. Keep the table QR page simple: menu, cart, send to kitchen.

Learn what you need on Sefism

• System design roadmap : event logs, pub/sub and idempotency are the core of this project.
• Backend cheat sheet : WebSocket and API patterns while you build the server.
• Discord Engineering : how a realtime system at scale thinks about delivery and reconnects.
• Zomato Blog : food service context and engineering posts from a restaurant platform.
• Grafana k6 Documentation : write the load and rush simulations.

Get help with this idea

The kitchen visit in week one decides whether this project is real. Tauseef can help you tighten the scope, choose a stack your team can finish with, and design an evaluation your examiners will respect. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session