HOLIXORAInternet connectivity in Indonesia has improved dramatically over the past decade, but it has not become uniformly reliable for every retail location in every city and district. A shop in a Tier 1 mall in Jakarta has different connectivity than a retailer in a secondary city running a small outlet in a shophouse.
Even in well-connected areas, there are connectivity interruptions. The question for a POS system is: what happens when connectivity drops?
The Binary Failure Problem
Basic cloud-native POS systems have a single answer to this question: they stop working. The interface may show an error state or simply become unresponsive. Transactions cannot be processed until connectivity restores. Staff either turn customers away or resort to manual recording on paper that has to be reconciled later.
For a retailer, this is not an abstract edge case. Connectivity interruptions during peak hours, when the internet is most congested, are the highest-cost failure scenario.
How Mercora Handles Offline Operations
Mercora runs a local data layer that keeps the POS functional during connectivity interruptions. When the connection to the central server is lost, the local layer takes over. Transactions process against locally cached inventory and pricing data. Receipts print normally. The customer experience is unchanged.
When connectivity restores, the offline transactions sync to the central server in the background. The sync process handles conflict detection — if a product was sold both at this outlet and transferred to another during the offline window, the system flags the discrepancy for review rather than silently applying one result over the other.
The Sync Architecture
The sync architecture for offline mode is the technically interesting part. Eventual consistency is easy to implement naively and hard to implement correctly. The cases that require careful handling are concurrent modifications to the same inventory record from multiple sources during an offline window.
Mercora uses a last-write-wins strategy with exception logging for inventory conflicts, combined with transaction-level conflict detection that flags cases where the offline record and the central record imply different states of the world.