Multi-Device POS Sync Without a Server

It is 7:42 PM. Your restaurant has four tablets running, a fixed terminal at the counter, and a kitchen display in the back. A server pockets a tablet to take a six-top order on the patio. The host punches a takeout into the front register. The bartender opens a new tab. Three different devices, three different orders, all arriving inside the same fifteen-second window.

Then the internet goes out.

What happens next depends entirely on how your POS handles multi-device POS sync. If every device is talking to the cloud, those orders pile up in local "offline mode" buffers and your kitchen display goes silent. If your devices can talk to each other directly, the kitchen sees every ticket in real time and your night never skips a beat.

This article explains how peer-to-peer mesh sync actually works, why most "multi-location" or "hybrid" POS systems are still server-dependent under the hood, and what changes when your devices stop needing a middleman.

The hidden cost of cloud-based multi-device sync

Walk into ten modern restaurants and nine of them will be running a cloud POS — Square, Toast, Clover, Lightspeed. Each of those vendors uses a similar architecture for multi-device coordination:

• Every terminal opens a persistent connection to a vendor-hosted cloud.
• When a server takes an order on Tablet A, the order travels to the cloud.
• The cloud forwards the update to Tablet B, the kitchen display, and the kiosk.
• Each device updates its local view from what the cloud says is true.

This works beautifully when your internet is healthy. The problem is the direction of the data. Tablet A is twelve feet from the kitchen display. The order it produced has to travel to a data center hundreds of miles away — and back — before the kitchen sees a ticket.

When the internet wavers, three things break at once:

• Tickets stop flowing between front-of-house and the kitchen, even though both devices are sitting on the same WiFi.
• Inventory deductions desync, so two servers can sell the last bottle of a wine they both think is in stock.
• Settlement records fragment, and end-of-night reconciliation turns into detective work.

Some vendors mitigate this with a local cache and a queue. That is better than nothing, but it is still a single-master architecture wearing a "hybrid" badge. The cloud remains the source of truth. When it cannot be reached, every device is operating in a degraded fallback.

Hybrid POS is not peer-to-peer

It is worth being precise here, because vendor marketing is not. A "hybrid POS" usually means one of two things:

• Local cache + cloud authority: Each device keeps a recent copy of menu and order data. Writes are still routed through the cloud (or queued for the cloud). Devices do not talk to each other directly.
• On-prem server + cloud backup: A back-office computer in the manager's office runs a small server. Tablets sync with that local server, and the local server syncs with the cloud overnight. If the back-office computer reboots mid-rush, the whole network stalls.

Neither of these is peer-to-peer. A real P2P mesh has no central coordinator, no "primary" device, and no required hop through a remote service. Every terminal is an equal node. Sync happens between the devices that actually need to share state, over the local network they are already on.

That distinction matters because the failure modes are completely different. A hybrid system fails when its cloud or its on-prem box fails. A P2P mesh fails only when every device disappears at once — and at that point you have a bigger problem than your POS.

What peer-to-peer POS sync actually is

A peer-to-peer POS network has three properties that a cloud system does not:

1. Direct device-to-device connections. Tablet A and the kitchen display open an encrypted, authenticated channel between themselves. Order events travel from one to the other directly, not via a cloud round-trip. POSAIC uses QUIC for this — the same transport protocol that powers HTTP/3 — because it is fast over local networks and survives WiFi handoffs gracefully.

2. Mutual authentication on every link. Every device in your restaurant has its own cryptographic identity. Before two devices share any data, they verify each other's certificates with mTLS. There is no "trust the LAN" assumption. A rogue tablet that wandered onto your WiFi cannot listen to your order traffic, because it cannot complete the handshake.

3. Gossip-based event propagation. When a device produces a new event — OrderCreated, PaymentReceived, ItemAdded — it gossips that event to every peer it can see. Each peer accepts the event, applies it to its own local state, and re-gossips. Within a few hundred milliseconds, every device on your local mesh has converged on the same view of the world.

The result is a sync model that does not depend on a single point of failure. Add a tablet, and it discovers its peers via mDNS (the same mechanism that lets AirDrop find nearby devices). Remove a tablet, and the mesh just routes around it. Lose internet entirely, and your local mesh keeps humming because nothing it needed required the internet in the first place.

This is the foundation of POSAIC's local-first architecture — every device is autonomous, every device is authoritative for its own state, and synchronization is something the devices negotiate among themselves.

How CRDTs prevent conflicts when devices disconnect

A natural objection: if every device is autonomous, what happens when two of them edit the same order while disconnected from each other? Doesn't that produce conflicting versions?

The answer is yes, and the answer is also that conflicts are not a problem if your data structure is designed to merge.

Most POS systems store the current state of an order in a row in a database. If two devices update that row independently, you have a real conflict — somebody's version of the truth has to be discarded. POSAIC stores orders as a sequence of immutable events instead. This is called Event Sourcing, and we cover it in detail in our event sourcing for POS guide.

When two devices are disconnected and each adds an event to the same order, the result is two event streams, not two conflicting rows:

Tablet A (offline): ItemAdded { order_id: 42, item: "Latte" }
Tablet B (offline): DiscountApplied { order_id: 42, discount: "10% loyalty" }

When the devices reconnect, CRDT merge rules apply both events. The order ends up with the latte and the discount, in a deterministic order, on every device. No human picks a winner. No data is lost. The merge is mathematical, not heuristic.

CRDT — Conflict-free Replicated Data Type — is a category of data structure with one defining property: any two replicas, no matter how badly out of sync, will converge to the same state once they exchange their pending updates. It is the same technique behind real-time collaboration in tools like Figma. Bringing it to POS means a busy tablet that fell off the WiFi for ninety seconds rejoins the mesh and reconciles silently, without a manager opening an "uh oh" dialog.

For event ordering across devices that may have slightly different clocks, POSAIC uses Hybrid Logical Clocks (HLC) — a timestamp scheme that encodes both wall-clock time and a logical counter, so events from different devices can be totally ordered without depending on perfectly synced system clocks.

A Friday rush with no internet — what actually happens

Let's run the same 7:42 PM scenario from the intro on a true P2P POS like POSAIC.

The patio server takes a six-top order on Tablet A. The order is recorded on the device immediately — local SQLite write, encrypted at rest with SQLCipher. Within roughly 200 milliseconds, every other device on the mesh — the counter terminal, the kitchen display, the bartender's tablet — has received the OrderCreated and ItemAdded events via gossip and updated its local view. The kitchen display prints a ticket. Total round-trip: a few hundred milliseconds, all on the local WiFi.

Now the internet goes out.

Nothing changes. The patio server keeps taking orders on Tablet A. The kitchen display keeps receiving them. The bartender keeps opening tabs on Tablet C. The host adds a takeout. Cash payments process. Card payments using pre-authorized terminals process. Inventory deducts. Every device has a complete, current view of every active ticket.

When the internet returns thirty minutes later, the cloud backup catches up in the background. End-of-night settlement runs against the same event log it always does. There is no reconciliation step, because there is no reconciliation needed — all devices were already in agreement the entire time. This is what reliable offline POS operation actually looks like in production: the failure mode is invisible to your staff and your guests.

Compare that to the cloud-POS version of the same thirty minutes:

• Tickets stop reaching the kitchen the moment connectivity drops.
• The kitchen runs on what the expediter remembers and what gets shouted across the line.
• Inventory diverges between devices.
• When the internet returns, the system replays a queue of buffered actions and hopes nothing collided.

The two scenarios produce wildly different customer experiences. The kitchen never sees the difference, which is exactly the point.

When cloud sync still makes sense

P2P mesh is not the right answer for every business. Being honest about that is part of how we write about POS:

• Single-device operations. A coffee cart with one iPad does not need mesh sync. A cloud POS is a perfectly reasonable choice when there is nothing to sync to.
• Heavy reliance on a single vendor's payment ecosystem. If you are deeply integrated with a vendor's bundled payment processing and hardware, the switching cost is real. Look at total cost of ownership over three years before deciding.
• No local network at all. A pop-up running entirely on cellular needs a different model. P2P mesh assumes the devices in your restaurant can see each other on a LAN.

Where P2P mesh wins is the case the existing market handles worst: multi-terminal restaurants with imperfect internet that cannot afford for the kitchen display to go quiet during a rush. That covers most independent restaurants, most multi-station cafés, most salons with multiple chairs running concurrent appointments, and most retail shops with a counter, a back-office laptop, and a tablet on the floor.

The bottom line on multi-device POS sync

If your POS uses a cloud server to coordinate multiple devices, your devices are essentially strangers to each other. They cooperate only through a third party. When the third party becomes unreachable, cooperation degrades.

A peer-to-peer mesh inverts that relationship. Devices know each other. They authenticate each other. They share events directly, in milliseconds, over the network they already share. The cloud becomes a backup destination — useful, but not load-bearing.

POSAIC was designed around this from the first commit. Every terminal, every kitchen display, every mobile tablet runs the same Rust core, joins the same encrypted mesh, and stays in sync without anybody calling out to a server. There are no per-device fees, no proprietary hardware, and no scenario where a fiber cut six blocks away can take your dinner service down.

If you have ever watched a restaurant grind to a halt because the WiFi blinked, you already know why this matters. Multi-device POS sync should be a property of your POS, not a service you rent from a vendor that can fail at the worst possible moment.

Next steps

• Read about the underlying event sourcing model that makes mesh merges deterministic.
• See the full POSAIC POS application and supported devices.
• Download POSAIC and stand up a two-device mesh on your existing tablets in under thirty minutes.