How the NX cloud platform keeps restaurants serving — at one location or four hundred
Executive summary
Restaurants have the least forgiving uptime profile in retail. Revenue arrives in a few concentrated hours, and the busiest ninety minutes of the week are the ones in which a stalled terminal becomes a line at the door. The work cannot be deferred: a guest who waited eleven minutes for a check does not come back later to pay it. And the building is rarely a data center — the network is usually a commercial broadband line shared with guest Wi-Fi and a camera system.
Every technology decision a multi-location operator makes runs into the same tension. The group needs one system: one menu, one set of numbers, one place to see every location. Each location needs to keep working when the connection to that system does not.
NX separates two jobs that most platforms combine. The terminals in the restaurant own service — taking orders, firing to the kitchen, splitting checks, taking payment. The cloud owns truth — the durable, shared record that every location, dashboard, integration and report reads from and writes to.
That separation is what makes the rest of this paper possible. Because the cloud never stands between a server and a guest, it can be built for what a shared system of record should be good at: capacity that is never estimated, redundancy in every layer, and tolerance for other people's outages. What follows is how that works and, more usefully, where it stops.
Three architectures dominate this market. Each answers part of the problem, and each breaks in a predictable place.
A server in the back office. How restaurant technology worked for thirty years, and the reasoning was sound: the store keeps working because everything it needs is fifty feet away. It breaks on the word one. One disk, one power supply, one fan, in a room that reaches 95°F in August — and when it fails, service stops until someone drives to the site. Redundancy is available and almost never bought, because it means a second machine at every location. Meanwhile the group view is a nightly export, so you learn about Friday on Sunday, and growth is procurement: forty new locations means forty installations, forty upgrade paths, forty backup regimes.
Rented servers in the cloud. Moving that machine into a data center removes the heat, the disk and the truck roll. What it does not remove is the sizing decision. You choose how much capacity to run in advance, for a peak you are estimating — and restaurants peak together, so your weekly average tells you nothing about the requirement. Estimate low and the shortfall lands on the best revenue night of the year. Estimate high and you carry idle capacity through the hundred-plus hours a week you do not need it. Someone also owns patching and upgrades, which means someone owns a maintenance window, which is a window during which several hundred people are eating dinner.
A browser terminal that depends on the cloud. The cleanest architecture on paper: nothing installed, everything central, one version everywhere. It also puts the guest-facing path behind the least reliable link in the chain and the one you control least — the site's internet connection. It does not take a full outage to hurt. Forty seconds of packet loss during a rush is enough, and a rush is when a shared consumer-grade line is least healthy.
NX takes the load-bearing strength of each: the local independence of the first, the elasticity of the second, the single shared record of the third.
2. The model: five independent questions
Most confusion about cloud reliability comes from treating it as one property — "is it up?" — when it is five questions with five separate answers.
Question
What answers it
Can this restaurant serve guests in the next five minutes?
The terminal, which holds what it needs to run service without asking
Where does the authoritative version of this information live?
The cloud system of record
Is there enough capacity for the busiest minute of the year?
Elasticity — capacity allocated per request, not per customer
What happens when part of the platform fails?
Redundancy — nothing in the platform exists only once
What happens when someone else's system fails?
Asynchrony — work that can wait, waits, on durable queues
These are genuinely independent. A platform can be extraordinarily scalable and still contain a component whose loss takes it down. It can be flawlessly redundant and still be too small on New Year's Eve. It can be both and still stop a restaurant cold, because it insisted on being consulted before a burger could be rung in. And all three can be true of a platform that goes dark whenever a delivery marketplace has a bad afternoon. Answering one of these well is common; answering all five is the design problem.
📊 Diagram: the five questions as layers — the terminal above owning service, the cloud below owning the record, the line between them crossable but not required.
3. The load-bearing idea, in practice
Everything above resolves into one sentence.
The restaurant does not ask the cloud for permission to serve a guest.
An NX terminal holds the menu, pricing, tax rules, open checks, employees and permissions it needs to run a shift. It rings in orders, calculates totals, prints to the kitchen, splits checks and closes them using what it already has. When the network is healthy — which is almost always — it publishes each event to the cloud immediately, and the cloud pushes it to every other terminal in the building within a moment. Publishing is a consequence of the work, not a precondition for it.
One Friday night
A six-location group. At 7:42pm on a Friday, a contractor cuts the fiber serving the flagship. Sixty-one guests are seated; nineteen checks are open.
Capability
During the outage
Ringing in orders, firing to the kitchen
Unaffected
Splitting, transferring, merging, closing checks
Unaffected
Cash payments and cash-out
Unaffected
Terminals in the building agreeing with each other
Unaffected
Card authorization
Needs a network path to the card processor, otherwise stored for future processing
Online and delivery orders arriving
Held outside the building; delivered on reconnection; orders & notifications sent to managers mobile devices
The group dashboard for that one location
Shows the last figures it received
The connection returns at 8:26pm. Every event from those forty-four minutes flows to the cloud, in order, and the location's numbers catch up within moments. Nothing was re-keyed. The other five locations were unaffected throughout, because they never depended on that building's connection. That is the entire difference between this model and a cloud-dependent one.
The unwelcome half. For forty-four minutes, the group dashboard for that location was stale. That is correct behavior — a report can only reflect what has reached it, and a system that guessed would be worse than one that waits — but it obliges the first habit in section 9: distinguish "the site is offline" from "the platform is down", because the responses differ entirely and the first case is far more common.
The other unwelcome half. If two terminals are cut off from each other as well as from the cloud, and both edit the same check, one edit has to lose when they reunite. NX resolves this by fixed rules rather than by asking a manager at 8:30pm: later information wins for facts a terminal owns, and lifecycle changes such as voided or closed are never silently reversed by an older message arriving late. It is deterministic, and it is not magic — reconciliation means somebody's version was not kept.
4. Mechanics
Three properties of the cloud side do most of the work, described here by what they guarantee.
4.1 Capacity is allocated per request
NX runs serverless. No machines are assigned to your group, no size is chosen on your behalf, and there is nothing to resize when you grow. Each request — a check saved, a report run, a delivery order arriving — is given its own compute, executed, and released. Ten requests a second and ten thousand are the same operation performed a different number of times.
Two consequences matter. There is no capacity number to outgrow, so acquiring twenty locations does not put a capacity project on your roadmap. And growth is not lumpy: traditional scaling happens in steps, and every step is a decision, a change window and a risk. Per-request allocation has no steps in it.
4.2 Nothing exists only once
Every layer — compute, the record itself, the message paths between devices, the queues — is spread across multiple physically separate data centers inside a region, each with independent power and networking. Records are written to more than one before the write is acknowledged.
The important word is acknowledged. Redundancy that must be activated is a plan; redundancy already carrying traffic is a property. There is no standby copy to promote and no failover procedure to rehearse, so there is none to get wrong at 7pm. The same posture applies to software: updates ship continuously into a platform with no maintenance window, because a maintenance window is a promise that some restaurant is not busy, and that promise cannot be kept.
4.3 Work that can wait, waits
The path a guest can feel — order, total, print, pay — is deliberately short. Everything else runs behind it on durable queues: sales aggregation, loyalty, accounting and payroll exports, marketplace synchronization, notifications, analytics.
This is the least visible property here and, in practice, the one that prevents the most incidents. Real-world outages are frequently somebody else's — a marketplace, a payment gateway, an accounting service. When one is slow, the work destined for it queues, retries at widening intervals, and completes when the partner recovers. Nothing in the dining room slows down, because the dining room was never waiting on it. Work that still cannot complete is set aside where support engineers can see it rather than discarded: the failure mode of a queue should be a delay you can investigate, not data you never knew you lost.
📊 Diagram: the short guest-facing path in front, queued downstream work behind it, and a third-party outage visibly contained to one queue.
5. Scale and resilience are not the same purchase
These two are merged more often than any other pair in infrastructure conversations, usually into "it's cloud, it scales". They answer different questions and are bought with different mechanisms.
Scale
Resilience
Question answered
How much can it handle?
What happens when something breaks?
The bad night it prevents
Slowdown when you are busiest
Outage at no particular time
When you notice its absence
Predictably, at 7pm on your best night
Without warning, on an ordinary Tuesday
Bought with
Capacity allocated per request
Redundancy in every layer, plus asynchrony
Verified by
Peak volume, observed
Component loss, absorbed
Swapping them produces a common error. A vendor who answers a resilience question with a scale answer — "we're on a major cloud provider, it scales automatically" — has not answered it, because automatic scaling says nothing about a lost component or an unresponsive partner. The reverse error is rarer and more expensive: immaculate redundancy, sized for the average, discovering on February 14 that redundancy does not create capacity. Ask both questions separately, of NX and of every vendor you evaluate.
6. Where the model deliberately stops
Several things this platform will not do are correct rather than missing. Knowing them stops you looking for a setting that should not exist.
Card authorization needs a live path to the card processor. No system can approve a card on a bank's behalf from inside a restaurant. NX's ambition is narrower and more useful: that a loss of connectivity stops only that, while the check, the order and the shift continue intact. In the event of a store-level connection outage, NX can store payment transactions for eventual processing.
Orders created outside the building cannot arrive during a local outage. An online or marketplace order is created on the internet, not in the restaurant. Those are held and delivered on reconnection. There is no local-first version of a message that never reached the building. NX can notify management via SMS & push notification of external order events, even when the store is offline.
Reporting is eventual, not transactional. Sales, labour and group roll-ups settle in seconds normally, and later if a location has been offline. They are deliberately not part of the transaction that closes a check, because making them so would make paying a bill as slow as the slowest report in the system.
A terminal is not a replica of the group. It holds what it needs to run service, not years of company history. Deep historical analysis is a cloud activity; asking a terminal to be a data warehouse as well would compromise the thing it is for.
"No capacity number to outgrow" is not the same as no limits. Distance is real — a request still crosses a country. Records live in a geographic region chosen deliberately. And third-party partners impose rate limits, which NX paces and queues against but does not abolish, because they are not ours to abolish.
That is by design, not an omission.
7. The rhythm of a day
During service, the guest-facing path is short and local, and each event reaches the cloud and the other terminals in the building typically within a second. Live figures on a manager's phone track the floor closely.
At end of day, a location declares its business day finished, and the day becomes a settled record rather than a moving one: totals finalised, cash reconciled, labour closed out, card batches submitted for settlement. End of day runs on each location's own clock, which is what lets a group span time zones without a platform-wide moment of truth.
Overnight, the settled day flows outward — to accounting, payroll, analytics, and anything else you have connected. Because that work is queued rather than synchronous, a partner unavailable at 2am receives its data later, without anyone being paged.
In the morning, group reporting reflects a complete, reconciled previous day for every location, including any that spent part of the evening offline.
8. Governance
The platform's behavior is now predictable. What remains is judgment. These are habits, and this is the section most worth circulating internally.
Treat the in-store network as infrastructure, not overhead. It is the one link NX cannot supply for you, and a second path at the site — typically cellular failover — is the highest-return reliability purchase available to a multi-location operator. It turns a forty-four-minute card-payment outage into a few seconds of rerouting.
Separate "my site is offline" from "the platform is down" in your escalation path. They present identically to a manager and have almost nothing else in common. Most reported outages are local, and a path that cannot tell the difference sends the wrong people to the wrong problem during dinner.
Never let a third party into your guest-facing path. If a loyalty, analytics or reservations integration requires a live call before an order can be taken, you have reintroduced that vendor's uptime into your revenue. Ask of every integration you commission: what happens in the dining room if this is down for an hour? The acceptable answer is "it catches up later".
Stop budgeting review time for capacity and spend it on dependencies. Per-request capacity removes the sizing question from annual planning. What replaces it are questions about partners, contracts and rate limits — which is where the remaining risk actually lives.
Roll significant configuration changes out the way you would roll out software. A menu restructure, a new tax configuration or a pricing change should be proved at one location before it reaches forty. The platform makes group-wide changes easy, which is precisely why the discipline has to come from you.
Review who can change what across the group whenever your organization chart changes. Central configuration is a strength and an aperture, and reorganizations do not happen annually.
9. Good to know
Adding a location is a configuration action, not a provisioning one. A new site runs on the same platform as the largest group on it.
There are no maintenance windows, and no version of NX your group is behind on.
Traffic is encrypted in transit, records are encrypted at rest, and both live in a region chosen deliberately rather than by default.
Every request carries a trace support engineers can follow. Most questions about what happened at a location on a given evening can be answered without visiting it.
Reporting and integration activity does not compete with the service path for capacity, because capacity is not a shared pool of machines.
Peak load is not something you pre-purchase, and idle locations cost close to nothing to keep online. There is no capacity reservation to true up.
10. Glossary
Serverless — Compute allocated per request and released afterwards, with no machines assigned to — or sized for — a particular customer.
Elasticity — Gaining and shedding capacity in proportion to demand, with no human decision and no step change.
Redundancy — More than one of everything, all of it live. Distinct from backup (a copy you restore from) and failover (a procedure you run).
Region — A geographic area containing several independent data centers, each with its own power and networking. Your records reside in a region you choose.
System of record — The authoritative version of a piece of information — in NX, the cloud, even when a terminal is temporarily the only place a fact exists.
Local-first — A design in which the device does the work with what it already holds and publishes the result, rather than asking permission first.
Eventual — Guaranteed to arrive and be correct when it does, without a guarantee of the exact moment. Applies to reporting and integrations, never to a check on a table.
Reconciliation — How separated copies of information agree again after a connection returns, by fixed rules rather than human arbitration.
Queue — A durable holding place for accepted but incomplete work. It absorbs the gap between when work arrives and when its destination is ready.
Asynchrony — Doing work in an order the guest cannot feel, so a slow dependency delays a background task instead of a transaction.
Degradegracefully — To lose one capability rather than all of them. A site that cannot authorize cards but can still serve, order and take cash has degraded gracefully.
End of day - The per-location moment a business day becomes a settled record, on that location's own clock.
Single point of failure — Any component with exactly one instance, whose loss stops the whole.