Journal

Why a restaurant POS should never lose a ticket

A dropped connection is a normal condition in a kitchen. Treating it as an error is how tickets disappear.

Quantum — 2025.11.09

The wifi in a restaurant is worse than the wifi anywhere else. There is steel between the router and the pass, a freezer that cycles, and forty phones that all joined at seven. Any system that assumes a connection will treat a Friday night as a series of failures.

Offline is not an error state

We build Quantum Restaurant so the terminal owns the ticket. An order is written locally the moment it is taken, and it is real from that instant. Sync is something that happens afterwards, in the background, and its failure is not the waiter's problem.

The kitchen does not care whether the server acknowledged the order. The kitchen cares that the order is on the rail.

This inverts the usual design. Rather than asking the server for permission to exist, the ticket exists and later reconciles. That requires identifiers generated on the device, a merge strategy for edits made in two places, and an honest answer for what happens when a terminal never comes back.

What it costs

Conflict resolution is real work, and you cannot avoid it by pretending conflicts do not happen. What you get in return is a kitchen that does not stop when the router does, and a floor team that never once has to say the words "it did not go through".

Written by Raion