Design a Restaurant Management System

The ask

Staff seat guests at a table, take an order, and send it to the kitchen. The kitchen cooks in order, and the table pays one bill.

Every terminal in the room shows the same table state. A drink added at the bar appears at the table terminal at once.

The service runs many restaurants. Each restaurant keeps working when its link fails.

Peak load is local and sharp. A full room orders within the same hour.

Estimate the scale

The service runs 100,000 restaurants. The average restaurant takes 200 orders a day.

100,000 restaurants x 200 orders = 20,000,000 orders a day.

20,000,000 orders / 86,400 seconds = 231 orders per second.

The average restaurant has 20 tables. That is a stated figure for one restaurant.

The global rate is modest. The real pressure sits inside one room at dinner time, where every table is active at once.

API and data

The seat operation takes a restaurant, a table and a party size. It returns an open table session.

The order operation takes a session and a list of items with notes. It returns the order and its kitchen state.

The bill operation takes a session. It returns every item, its price and the total due.

A table session holds a restaurant, a table, a server, an open time and a state. The state is open, billed or closed.

An order holds a session, items, a course order and a state per item. The state moves from sent to cooking to served.

High-level design

Each restaurant runs a local hub on its own network. Terminals, kitchen screens and printers talk to the hub.

The hub owns table sessions and orders for its room. One room has one writer for its state.

A central service holds menus, prices and reports for all restaurants. Menu changes flow down to hubs before service starts.

Kitchen screens subscribe to new orders from the hub. A subscription here means the screen receives each new order as it happens.

Payments run through the hub to a payment service. A card result attaches to the session bill.

Deep dive: one table, many hands

A table session is shared state under contention. Many staff touch the same session within seconds.

The session opens in one atomic step. A second terminal sees the open session and joins it.

Items are added as separate lines, never as edits to one shared list. Two additions cannot overwrite each other.

A removal marks a line void with a reason and a staff name. The line stays visible on the bill history.

The bill sums non-void lines only. Kitchen screens and bills read the same lines, so the room never argues about an item.

Deep dive: the kitchen queue

The kitchen works a queue ordered by course and by time. Starters leave before mains for the same table.

Each item carries the time it was sent. A screen sorts by course first and by waiting time inside the course.

A rush order moves ahead with a manager action. The move is recorded, so the order of work stays explainable.

A fired item cannot be voided silently. The kitchen confirms the void, because the food may already exist.

When the link or the hub fails

A lost internet link stops card payments and central reports only. Seating, ordering and cooking continue on the hub.

The hub stores every session and order locally first. Reports sync when the link returns.

A dead hub is harder. Terminals hold the last known state and switch to paper tickets until a spare hub takes over.

The spare hub restores state from the hub backup on the local network. Open sessions survive with their items intact.

Evaluation and trade-offs

One writer per room keeps table state exact. A room is small enough that one hub carries its dinner peak.

Local-first design keeps service moving through outages. The price is a sync step and a spare-hub routine.

Shared, exact table state is the core promise. A restaurant management system earns trust when the bill always matches the table.

Reports can wait for the sync. Orders and bills cannot wait at all.

Scale at a glance