Cloud POS Systems - The Engineering Behind Your Restaurant Bill

A restaurant point of sale system is a distributed systems problem wearing an apron.

Several terminals share mutable state. The network partitions regularly and without warning. Concurrent writes to the same record are routine rather than exceptional. And the resolution of a conflict has a direct financial value, because a merge that goes the wrong way either charges a customer for something they sent back or fails to charge them for something they drank.

Anyone who has thought about append-only records and deterministic state derivation will recognise the shape of the solution immediately.

The partition is the normal case

Most systems treat network partition as an exception. In a restaurant it is a scheduled event.

The venue runs consumer broadband shared with a card terminal, a music box and a guest wi-fi network carrying half the dining room. It degrades during exactly the hours that matter, and nobody in the building can diagnose it.

So the terminal cannot be a client of a remote authority. It must hold its own durable state, write locally and synchronously, and treat synchronisation as background reconciliation. Any user action that waits on a network response is a failure waiting for a bad evening.

Identifiers are generated on the device. Universally unique, never server-assigned sequences, so an order created during a partition has real identity from the moment it exists rather than a provisional one that must be rewritten later.

Append-only records, derived state

Here is where the principle familiar from ledger design applies directly.

Do not represent a bill as a mutable document that terminals overwrite. Represent it as an append-only sequence of operations: item added, item voided, discount applied, seat assigned. Each carries a device-generated identifier, a per-device sequence number and a logical clock.

Current state is a fold over those operations. Two devices that diverged during a partition are merged by unioning their operation sets and replaying deterministically.

Compare the naive alternative. Overwriting at the document level means whichever version syncs second silently discards the other device's work. The bar added wine; the till voided a starter; one of those is now lost. In one direction the customer is billed for a returned dish, in the other the restaurant never collects for the wine. Both are real losses and both destroy the operator's trust faster than almost any other defect.

A detail worth stating: do not order by wall-clock time. Device clocks drift, and clock-ordered merges are non-deterministic across replicas. Logical ordering only; timestamps for display and audit.

What genuinely cannot be merged

Honesty about limits is better than a merge strategy that pretends to solve everything.

Settling a bill from two terminals concurrently must not both succeed. Voiding an item the kitchen has already cooked and served is a business decision, not a data merge. Anything with an external side effect — a refund issued, loyalty points redeemed — cannot be quietly reconciled.

Define that set explicitly, require connectivity for it, and show the requirement in the interface. Where settlement must survive an internet outage, a coordinator elected among terminals on the local network shrinks the failure domain from the internet to the local switch.

Visible failure beats silent failure in this environment without exception. Staff need to know they are offline and work is queued.

Bound the divergence

Define a maximum offline window — one service day is typical. Past it, a terminal requires reconciliation before accepting new work.

This is not only a correctness measure. It makes conflict testing a finite problem, which permits property-based testing over generated operation sequences: assert that any interleaving of two divergent streams folds to identical state. Example-based tests miss ordering bugs reliably, and the failure mode here costs money.

Keep the operations, not the totals

One last architectural point, and it is the one with the longest consequences.

Store item-level, timestamped operations including modifiers and voids. Do not collapse them into settled bill totals.

That detail is the input to demand forecasting at item level, which drives prep and supplier ordering; to labour scheduling derived from those forecasts; to menu engineering; and to anomaly detection that flags a venue whose void rate has departed from its own baseline. These are the features that reduce food and labour cost, which are the only costs an operator genuinely cares about.

History discarded at this layer cannot be reconstructed. It is a week-three decision that determines what is possible in year two.

Full build guide: Cloud Based Restaurant POS Systems: The 2026 Build Guide

Frequently Asked Questions

Is this the same as using a blockchain?

No. The shared principle is immutable records with derived state, but the problem here is deterministic convergence between devices under the same owner, not trust between adversarial parties. A local append-only store plus deterministic merge is sufficient and far simpler.

Would CRDTs solve this completely?

They cover most of it — operation-based semantics fit adds, modifications and voids well. What they cannot cover is the arbitration set, since settlement and served-item voids are business constraints requiring single authority rather than merge conflicts.

How long can a terminal safely stay offline?

Bound it to about one service day. Longer windows produce merges nobody can reason about and staff cannot explain to a customer, and they make the conflict space impractical to test.

What local storage suits a terminal?

Anything durable with transactional writes — SQLite on native platforms, IndexedDB in a browser. The critical property is that writes are synchronous from the user's perspective and never block on network availability.

Why not just require reliable internet in the venue?

Because you cannot. The connection is consumer-grade, shared with several other devices, and outside the software vendor's control. Designing for a reliable network in this environment is designing for conditions that do not exist.