What "works offline" actually means for a restaurant POS

Every cloud POS says it works offline. Very few explain what that sentence covers, and the gap between the claim and the behaviour is only discovered on the worst evening of the year.

Offline is a queue problem, not a screen problem

Any app can cache a menu and render a screen without a connection. That is the easy half. The hard half is what happens to the twenty orders, four refunds and one closed shift that were created while the line was down.

Those are not screens. They are facts that other people’s numbers depend on — stock, the kitchen, the books, the cashier’s drawer. Getting them back in the right order, exactly once, is the whole engineering problem.

What the till must keep doing

Without internet, a POS still has to:

• Open a shift and take an opening float.
• Show the full menu, with prices, modifiers, variants and combos.
• Take orders, hold them, split bills, apply discounts and promo codes.
• Take cash payment and print a receipt on a locally connected printer.
• Void and refund with the same approval rules as normal.
• Keep counting the drawer so the close still balances.

That is a working restaurant. Nothing on that list needs a server to be true.

What genuinely cannot work

Honesty here is a feature, not a weakness:

• Card and online payments. A gateway authorisation needs the gateway. You take cash, or you take the card when the line returns.
• Live cross-branch views. Another branch’s stock is a fact that lives on the server.
• Anything a second device must see instantly. A kitchen screen on the same local network can still be served, but a phone on mobile data cannot be told about a ticket by a till with no uplink.

A system that claims all of this works offline is either wrong or redefining “offline”.

How the catch-up is made safe

When the connection returns, the device does not simply resend. Each action was written locally as an immutable record the moment it happened, carrying:

The server stores these with a unique key on (deviceId, clientActionId). If the same action arrives twice — flaky wifi, an app restart, an impatient retry — the second one is recognised and the original result is returned instead of creating a second order. Payments carry an idempotency key for the same reason: a retry can never charge twice.

Retries back off gradually rather than hammering the connection, and anything that still fails after the retry threshold is dead-lettered where a manager can see and resolve it, instead of silently disappearing.

When two tills disagree

This is the question worth asking any vendor. Two tills go offline. Both sell the last five portions of the special. Both come back at once.

There is no magic answer — the portions do not exist. What matters is that the system is deterministic about it and tells you:

• Stock that would go negative is rejected with an actionable error rather than quietly accepted.
• Order status only moves along valid transitions, so a “served” ticket cannot be reopened by a late arrival.
• A payment larger than the order total is rejected.
• Table state takes the server’s authoritative version, because two people cannot be sitting at table 6.

You will still have to comp a dish. But you will know, at the moment it lands, instead of finding a negative stock line three weeks later.

The one-minute test

Before you sign with anyone, do this in the demo: put the tablet in flight mode, take four orders, refund one, close the shift, then turn the connection back on. Then check three screens — stock, the kitchen history and the day’s sales — and see whether all four orders are there, once each, in the right order, with the refund reversed.

That test takes a minute and tells you more than any feature list.