Offline-First POS: Conflict Resolution and Data Consistency
This article discusses architectural decisions for building an offline-first Point-of-Sale (POS) system that maintains data consistency and operational resilience despite intermittent network connectivity. It highlights strategies for conflict resolution, idempotent transactions, and event-based stock management to ensure sales can continue uninterrupted and data merges cleanly once reconnected.
Read original on Dev.to #architectureDesigning systems for unreliable network environments, especially in critical operational contexts like retail Point-of-Sale (POS), demands an offline-first approach. This architectural pattern prioritizes local operations and defers synchronization, treating online connectivity as an optimization rather than a prerequisite. The core challenge lies in ensuring data consistency and resolving conflicts that arise when multiple clients operate independently and then attempt to merge their changes.
Key Principles for Offline-First Data Consistency
- Idempotent Sales Transactions: Generate transaction IDs on the client side (e.g., using UUIDs). This allows sales to be retried multiple times without being duplicated on the server, simplifying the synchronization logic and making the system resilient to network retries.
- Event-Based Stock Management: Instead of syncing absolute stock counts, transmit and store stock *events* (e.g., "sold 3", "received 10"). This transforms stock updates into an append-only log, where additions are commutative, significantly reducing data merge conflicts and providing a clear audit trail. The current stock quantity becomes a reduction over this event stream.
- Deliberate Conflict Resolution: Recognize that not all conflicts are mergeable data problems. Business-level conflicts, such as two tills selling the last unit of an item, require policy decisions rather than algorithmic merging. The article suggests allowing both sales to proceed, flagging the item as oversold, and surfacing it for manager intervention (e.g., quick restock or refund) to prioritize uninterrupted sales over immediate perfect data consistency.
Offline-First Mindset
When connectivity is unreliable, design for the disconnected state first. Treat online synchronization as an eventual consistency mechanism and an optimization for data freshness, not as the primary mode of operation. This simplifies architecture and improves user experience during outages.
Avoidance: Live Sockets for Unstable Networks
The article explicitly advises against relying on continuously open live sockets with aggressive reconnection attempts in environments with patchy connectivity. While this might seem to offer instant feedback on the 'happy path,' it often leads to complex, hard-to-reason-about error states on the 'unhappy path.' An offline-first approach, involving local writes, a queuing mechanism for outgoing changes, and a robust reconciliation process, proved simpler to build and more reliable in practice.