Building a POS That Survives Internet Outages
Offline-first architecture patterns we used to ship a POS that never stops selling — even mid-outage.
A point-of-sale system that stops selling when the internet drops is a point-of-failure, not a point-of-sale. Here's how we built NovaMart's POS to keep ringing sales through a full regional outage — and reconcile cleanly afterward.
The goal: never stop selling
Retailers lose real money every minute a checkout is down. So we set a hard requirement: the POS must complete a sale with zero network connectivity, and sync everything the moment a connection returns.
Architecture: offline-first by default
The core pattern is a local-first data layer. Every terminal runs a local embedded database (SQLite) that is the source of truth during a transaction. Sales write locally first, then replicate upstream.
Terminal (SQLite) ──sync──▶ Regional hub ──sync──▶ Cloud HQ
- Writes go local — transactions commit in milliseconds, offline or online.
- Sync is async — a background queue pushes changes when a link is available.
- Conflict resolution — last-write-wins per field with an append-only audit log.
Inventory that stays honest
The trickiest part is inventory. We reconcile using an event-sourced model: every sale, return and adjustment is an immutable event. The current stock is a projection of those events, recomputed deterministically. That makes multi-branch merges conflict-free, even when branches were offline for hours.
What we learned
- Design for the worst network first; online is just an optimization.
- Keep the local schema small and the sync payloads tiny.
- Make reconciliation idempotent so duplicate syncs are harmless.
- Surface a clear "offline mode" indicator to staff so trust stays high.
The result: 47 branches, a regional outage, and not a single lost sale. Offline-first isn't a feature — it's the architecture.