Designing software for networks that drop

Software built in places with good connectivity treats an outage as an error state. Something went wrong, show a spinner, try again. Build for a shop in Accra and that assumption breaks immediately, because the outage is not the exception. It is Tuesday.

Offline is the normal case

The distinction that matters is not whether an application handles being offline, but whether it treats offline as a failure to recover from or as an ordinary condition to operate in. The first produces software that technically does not crash. The second produces software a cashier can keep using without noticing anything changed.

You cannot retrofit the second from the first. It decides where data is written, how records are identified, and what the application is allowed to promise the person using it. Those are foundational choices, which is why offline-first is a decision made at the start or not at all.

Where the truth lives

In a conventional application the server holds the truth and the client asks permission. Take the network away and the client can do nothing, because it was never trusted to decide anything.

Offline-first inverts that. The device holds a complete, authoritative record of what happened at that counter. The server's job becomes reconciliation rather than permission: it collects what each device recorded and merges it. A sale is real because it happened at the till, not because a server acknowledged it.

The same sale, sent twice

Once a device queues work for later, duplicates become inevitable. The connection returns mid-upload, an app restarts, someone retries. If the system counts every message it receives, the shop's takings inflate and its stock goes wrong.

The fix is that each sale carries an identifier generated on the device at the moment of the sale, and the server treats a repeat of an identifier it has already seen as the same event rather than a new one. Send the same sale twice and it counts once. That property is worth testing explicitly, because it is easy to claim and easy to get subtly wrong, and the symptom only appears on a bad connection with a busy till.

Numbering without a central authority

Receipt numbers are where offline design meets the tax rules. A sequence handed out by a central server is simple until the server is unreachable, at which point the till either stops selling or invents a number that may collide with another branch's.

Workable approaches give each device its own range or its own prefix, so two tills can never produce the same reference, and the sequence stays auditable when the pieces are brought back together. The requirement to keep in view is that an auditor should be able to account for every number, including the gaps.

Stock is the hard part

Sales merge cleanly because they are additive. Two tills selling while offline produce two sets of sales, and the union is simply all of them.

Stock does not behave that way. Two branches can each sell the last unit of something while neither can see the other. No merge strategy fixes that after the fact, because the physical goods have already left both shops. What software can do is make the reconciliation visible rather than silent, so somebody knows a discrepancy exists and can deal with it, instead of discovering it at a stock count months later. Anyone promising perfect multi-branch stock accuracy over an unreliable link is describing something other than the physics of the situation.

What to ask a supplier

Ask what happens if you unplug the router mid-sale, and watch rather than listen. Ask whether you can keep selling for a full day offline, not five minutes. Ask what happens when the same sale reaches the server twice. Ask how receipt numbers are allocated when the server is unreachable, and how two branches avoid colliding.

The answers tell you whether the offline behaviour was designed in or bolted on. We build our own point of sale product on these lines, so the opinions above are the ones we had to hold ourselves to.