Building for intermittent connectivity

A pharmacy counter in Dhangadhi does not stop having customers because a fibre line was cut in transit. Neither does a church office on a Saturday morning. Software that assumes a working connection is not doing its job here.

“Offline support” is easy to say and hard to mean. The honest version is a set of specific decisions, most of which have to be made early because they are difficult to retrofit.

Decide what must work offline

Not everything should. Trying to make an entire application work without a server produces something slow, complicated and full of conflicts. The useful question is which operations cannot wait.

• Selling must never block. A customer is standing there. This is non-negotiable.
• Looking up stock and price must work. It is part of selling.
• Receiving a delivery can tolerate a short wait, though it is much better if it does not.
• Reports, user administration and settings can require a connection. Nobody is blocked at a counter by a monthly report.

Drawing that line explicitly is most of the work. It converts “make it work offline” into a bounded problem.

Identifiers have to be assigned locally

The classic mistake is letting the database issue the identifier. If a sale’s ID comes from a server sequence, a sale cannot be recorded without the server, and the whole design collapses at the first outage.

Identifiers must be generated on the device, in a form that cannot collide with another device’s. Human-facing document numbers are a separate concern: they usually need to be sequential and gapless, so let them be assigned on sync and shown as pending until they are.

Conflicts are a business question, not a technical one

Two devices selling the last unit of the same item is not a merge problem. It is an oversell, and the right resolution depends on the business — not on which write arrived at the server first.

We treat the sale as the immutable fact. Both sales happened; both are recorded. The stock figure goes negative and is surfaced as an exception for a human to settle, rather than being silently corrected. A quietly discarded transaction is far worse than a visible discrepancy: one is an accounting problem, the other is a trust problem.

Make the state visible

Staff need to know, without asking, whether what they are looking at is current. A quiet indicator showing connection state and the count of unsynced documents does more for confidence than any amount of background cleverness. When people can see that seven sales are waiting to sync, they stop worrying about whether the sales were recorded.

None of this is exotic. It is mostly the discipline to decide early, to keep the offline surface small, and to refuse to hide a conflict that a person should see.