NX: Offline-First

How NX keeps a restaurant running when the network does not — and what that obliges you to manage instead.

Executive summary

A restaurant cannot pause. When the internet drops at 7:40 on a Friday there is no queue to hold, no retry screen a guest will tolerate, and no version of "please wait" that does not cost money. Every other industry gets to treat connectivity loss as degraded service. A restaurant has to treat it as an ordinary Friday. That collides with how modern software is built: most business applications assume the network and tolerate its absence as an exception. Restaurants need the inverse.

NX is built so that a station's ability to do its job never depends on anything outside the building. Each station holds its own complete copy of what it needs to operate, writes every action to that copy first, shares with the other stations over the restaurant's own network, and forwards to the cloud when the cloud is reachable. There is no mode switch, no reconnect dialog, and no end-of-day reconciliation ritual, because the network was never in the critical path.

The trade is real, and this paper is mostly about it. Remove downtime as a failure mode and you inherit staleness — a device that works perfectly while knowing something that is no longer true. The operational burden moves from "keep the circuit up" to "keep the devices current," which is a cheaper discipline but not a free one.

Contents

1. Why the alternatives fail
2. The model: four independent questions
3. The load-bearing idea, in practice
4. Mechanics I — what every station carries
5. Mechanics II — agreement between stations
6. Mechanics III — reaching the cloud
7. Mechanics IV — cards when the line is down
8. A worked outage
9. The conflation: offline vs. stale
10. Where the model deliberately stops
11. Timing
12. Governance
13. Good to know
14. Glossary

1. Why the alternatives fail

A browser-based or thin-client POS. The terminal renders; the cloud decides. This is the cleanest architecture available, because there is exactly one copy of the truth. It fails on physics: every tap is a round trip, so ordinary latency shows up as a slow terminal during the rush, and a circuit failure turns a tablet into a tray. Vendors patch it with a read-only cached mode that can show a menu but not reliably close a check — the half of the job involving money.

A back-office server as the local authority. Put the truth on a box in the building; terminals talk to it; it talks to the cloud. This genuinely works offline, and was the right answer for twenty years. Its problem is that you have built a single point of failure, given it a hot closet, and made it restaurant equipment. When it fails, every station fails together, and a correlated outage is worse than the one you were avoiding. It also needs an owner — a role most operators do not staff.

Cloud-primary with an offline fallback mode. Run online, detect failure, switch to a local mode, reconcile on the way back. The most common design and the most seductive, because it looks like both. The defect is structural: there are now two code paths, and the one that runs during your worst hour of the year is the one exercised least. Reconciliation is also concentrated — everything the venue did arrives in one burst, exactly when conflicts and ordering problems surface. The mode switch, not the outage, produces the support call.

NX takes the last approach's goal and removes its mechanism. With no online mode, there is nothing to fall out of.

2. The model: four independent questions

Operators, and most vendors, use "we're offline" as one condition. It is four.

These are genuinely independent, and almost every confusing incident is a mix-up between two rows.

The internet can be down while the local network is healthy: stations see each other, printers print, the kitchen display updates, and the only symptom is that the office numbers stop moving. The reverse is more disruptive — the internet is fine, a switch has failed, and each station works alone, unable to see its neighbours' checks or reach a printer. Card processing fails on its own schedule, because the processor is a different company with a different outage calendar. And one station can be the only offline device in a healthy building, because Wi-Fi is a per-device condition, not a venue condition. Handhelds live at that edge.

Diagnosis starts by asking which row failed. "We're offline" is not yet a diagnosis.

🖼️ Diagram: four separate dependency lines from one station — resident copy, local network, processor path, cloud sync — showing that cutting any one leaves the others intact.

3. The load-bearing idea, in practice

Every station runs as though the network were already gone.

Not can run. Does run. A card tender, a seat split, a clock-in, and a voided item all complete against the station's own copy and are done at that moment. Telling the other stations and telling the cloud happen afterward, and cannot fail an action that already succeeded.

Three consequences follow, and they explain the rest of the system. Connectivity loss is not an event — staff usually do not notice one, which is intended rather than a monitoring gap, because there is no behaviour to warn them about. Recovery is not an event either: nothing accumulates for a nightly batch, so the queue drains in the background and the office numbers resume. And the uncomfortable one: a station that never asks permission also never learns that the world changed. A price edited in the back office this morning does not reach a station unreachable since yesterday. That station is not broken. It is faithfully doing the last thing it was told.

4. Mechanics I: What every station carries

Each station holds a working copy of everything needed to run the venue unaided: the full menu with pricing, modifiers, and scheduled prices; tax rules; floor plans, tables, and areas; staff, jobs, and permissions; discounts, fees, and order types; printer and kitchen routing; and every check it has touched, in full. Customer records are held in a lightweight form, enough to find a guest by name or phone — anything carrying a balance is deliberately not trusted from it.

This is not a cache of recently used data. It is complete enough that a station carried out of the building would still run a full service on what it left with, and that completeness is what makes it the station's primary source rather than its fallback.

5. Mechanics II: Agreement between stations

Stations share directly with each other over the restaurant's own network. There is no master station and no election: any station can be powered off, dropped, or replaced mid-service without the others reorganizing, because none of them depended on it. A station that cannot reach a printer itself will ask a peer that can, rather than failing the chit.

So during an internet outage the floor still behaves as one system. A check opened at the bar is visible at the server station, transfers work, chits print. None of that involves the cloud — and none of it involves the cloud on a good day either. Printing and kitchen routing are always local, which is why an internet failure does not touch them.

The sharp edge. If the local network splits, two stations can each edit the same check believing they are alone. When they meet again the versions merge per detail rather than per check: the most recent change to the guest count wins for the guest count, the most recent change to a discount wins for the discount, and unrelated edits on both sides survive. That is correct, and better than one station's whole version overwriting the other's. But if two managers apply different discounts to the same check on opposite sides of a split, one of those decisions will not survive. What it obliges you to do is operational: keep one person on a check, and treat simultaneous editing as a habit to discourage rather than a capability to lean on.

6. Mechanics III: Reaching the cloud

Completed work is queued and forwarded record by record, not as an end-of-day batch. Connected, this happens within seconds and is invisible. Disconnected, the queue holds and retries while the venue keeps operating on top of it. Two properties matter to you.

Recency decides, per detail. When the same record changed in two places, the more recent change to each individual detail survives. A back-office edit and a station edit do not overwrite each other wholesale.

The station's record of a check is the one that counts for that check. The cloud assembles, reports, and audits the day; the station is where the day happened. That is why an outage check arrives complete rather than approximated, and why it lands on the correct business date even if it uploads the next morning — the timing came from the station that took the order, not from the moment of upload.

The sharp edge. While a venue is disconnected the office sees numbers that are stale, not wrong. Nothing is lost and nothing needs re-entering, but a figure pulled mid-outage is partial. That is intended — the alternative is blocking the floor until the office can see it — and it obliges you to stop using live dashboards as outage detection. A quiet number is a connectivity signal, not a sales signal.

7. Mechanics IV: Cards when the line is down

Authorizing a card requires a path to the processor, and no local architecture can invent one. What NX can do is stop that from stopping service: card transactions can be captured at the terminal and held, then forwarded automatically once the processor is reachable. Cash and anything settled in the room are unaffected in every case.

The sharp edge. A held transaction has not been approved. Most approve on forwarding; some do not, and that decline arrives after the guest has left. This is a commercial risk the venue chooses in exchange for continuing to serve — the one part of offline operation that is a business decision rather than a technical one. It obliges you to set the policy in advance: whether holding is enabled, up to what ticket size, and who may override. Not something a shift lead should decide under pressure at 8pm.

8. A worked outage

One venue, one evening. The circuit fails mid-check on table 14.

Two rows carry the paper. Nobody had to do anything at 8:19; recovery required no action, which is the whole point. And the only visible failure all evening — the redemption at 8:11 — failed on purpose.

9. The conflation: offline vs. stale

These are the two conditions operators merge, and merging them is the most expensive misunderstanding available here.

Swapping them goes wrong both ways. Hear "the POS works offline," conclude that a spare tablet can sit in a drawer for three weeks and come out current, and you have confused staleness for downtime: it will come out working, confidently selling last month's prices. See an old price and file it as a sync fault and you have made the reverse error, spending the call on the network instead of asking how long that device has been unreachable.

The reframe: NX converts a downtime problem, which is urgent and expensive, into a freshness problem, which is cheap and schedulable. You still have to schedule it.

10. Where the model deliberately stops

Anything holding a balance fails closed. Gift card values, loyalty point balances, and house account limits are not honoured from a local copy when the authoritative figure cannot be confirmed. A guessed balance creates money to be clawed back from a guest who has gone home. A refusal costs one apology; a wrong balance costs a write-off and a phone call.

Configuration cannot be authored from a station. Prices, menu structure, staff records, and permissions are edited in one place. If every station could author configuration while disconnected, every station would become a competing source of truth for what a burger costs, and no merge rule makes that come out right. Stations consume configuration; they do not originate it.

Orders that arrive over the internet cannot arrive without it. Online, delivery, and QR orders are held upstream and land when the connection returns.

Estate-level reporting is a cloud function. A station computes its own shift-level numbers offline. It does not hold other venues' data and cannot assemble a comparison it has no inputs for.

First-time provisioning needs a connection. A station must be told which venue it belongs to before it can be independent of the thing that told it.

That is by design, not an omission.

11. Timing

The last row surprises people. The business date follows the venue's own day definition, so late-night trade lands where the operator expects it and an outage cannot move revenue into the wrong day.

12. Governance

Downtime is already handled. These habits manage what is left.

• Ask which of the four questions failed before touching anything. Printers and kitchen displays dying during an outage is a local-network symptom, not an internet one, and the remedies differ.
• Never let a device go dark and expect it current. Power up spares and seasonal handhelds on a schedule, and give any device that has been off a few minutes on the network before it takes an order.
• Put the offline card policy in writing before you need it. Enabled or not, up to what amount, who may override. The only part of this model that is a risk decision.
• Prove that any single station can be lost. On a slow shift, power one off mid-service and confirm nothing needed rescuing. If that test is frightening, something has been made to depend on one device.
• Treat the local network as production infrastructure, not office furniture. It is what the floor genuinely depends on now. Switches, access-point placement, and handheld coverage deserve the attention that used to go to the internet circuit.
• Keep one person on a check. Simultaneous editing is survivable, not free.
• After an extended outage, confirm the queue drained before closing the day. It normally has. Confirming is a ten-second habit that surfaces the abnormal case while someone is still on site.
• Watch freshness as a metric, not an incident. "When did each device last hear from us?" is worth more than any uptime figure, because it is the number that predicts a guest seeing the wrong price.

13. Good to know

• Printing and kitchen routing never involve the cloud, even when the cloud is available.
• Clocking in and out works offline; the time comes from the station and the entry syncs later.
• A station can produce its own shift-level report while disconnected.
• Diagnostic logs are kept on the device as well as sent up, so investigating an outage afterward is not blind.
• A long-offline station catches up in the background rather than blocking the operator, so it can be handed to staff before it has finished.

14. Glossary

Offline-first — Designing so local operation is the normal path and the network is an accelerator, rather than treating disconnection as an exception to be handled.

Resident copy — The complete working copy of the venue's operating data on each station. Not a cache of recently used items.

Sync — The continuous, record-by-record exchange between station and cloud, in both directions. Not a batch, and not tied to end of day.

Peer — Another NX station in the same building, reachable over the restaurant's own network without going through the cloud.

Stale — Working correctly on information that is no longer true. The characteristic failure of an offline-first system, and distinct from being offline.

Fail closed — Refusing an action rather than guessing, when the authoritative answer cannot be confirmed. Applied to anything holding a balance.

Held transaction — A card payment captured at the terminal while the processor was unreachable, then forwarded automatically. Captured is not approved.

Business date — The venue's own definition of an operating day, which does not end at midnight. Work is attributed to the business date on which it was taken.

Converge — What two separately edited copies of a record do when they meet: the more recent change to each individual detail survives, rather than one whole version replacing the other.

Authoritative — For a given fact, the copy that decides. The station decides what happened on it; the cloud decides configuration and the assembled day.