The internet will drop mid-shift. Whether that costs you a sale — or nothing at all — comes down to one architectural choice.
Every operator has lived it: a busy rush, and the Wi‑Fi blinks. On a cloud-only register, the line stops. Orders can’t be rung, cards can’t be taken, and the shift turns into an apology tour. The problem isn’t the outage — outages are inevitable. The problem is a system that treats the network as a requirement instead of a convenience.
What “offline-first” actually means
Offline-first isn’t a fallback screen. It means the register is fully functional with no connection at all: it holds the catalog locally, computes tax and discounts on the device, records the sale durably, and prints a receipt — then syncs to the cloud when the connection returns. The cloud becomes where data goes, not something the sale depends on.
The hard part is the sync, not the sale
Ringing a sale offline is straightforward. The engineering that matters is what happens when the connection comes back:
- The sale must survive a crash or a battery pull — not live only in memory.
- When it finally reaches the server, it must land exactly once — a reconnect can’t create a duplicate charge or a phantom order.
- It must be attributed to the right merchant, with isolation enforced so no one else’s data is ever in reach.
A register that keeps selling offline is table stakes. A register that syncs exactly once when it comes back is the real engineering.
How NorthStar approaches it
The NorthStar register persists completed sales on the device so they survive process death, then drains them to the cloud through an idempotent path keyed to a client order id — so a retry is a no-op, not a double. Isolation is enforced at the database layer, not in application code you have to remember to write correctly. These are the parts we’ve proven on real devices, because “it works on Wi‑Fi” isn’t the claim that matters.
If your current POS turns an outage into lost revenue, that’s not bad luck — it’s an architecture choice you can change.