Building POS Systems That Work Offline
Designing for unreliable networks, data consistency, and the reality of retail branch operations.
Point-of-sale systems have a unique architectural constraint that most software doesn't face: they must work when the network doesn't. A retail branch that can't process sales because the internet is down isn't just an inconvenience — it's lost revenue, frustrated customers, and operational chaos.
Offline-First Architecture
Offline-first isn't "add caching." It's a fundamental architectural decision that affects every layer of the system. The local device must maintain enough state to operate independently — product catalog, pricing rules, tax calculations, and transaction history.
This means the POS terminal is not a thin client. It's a local system with its own data store, business logic, and sync engine.
The Sync Problem
Synchronization between offline terminals and the central server is the hardest problem in POS architecture. Conflicts are inevitable: a price changed centrally while a branch was offline, a product was discontinued while a sale was in progress.
Conflict resolution strategies must be defined per entity type. Last-write-wins works for some data. Operational transformation works for others. Some conflicts require human resolution through exception queues.
Multi-Branch Complexity
Scale this to dozens or hundreds of branches, each with multiple terminals, and the complexity multiplies. Staggered sync schedules, bandwidth constraints, and hardware variability all become architectural concerns.
The systems that succeed are those designed for the exception, not just the happy path.