Offline-first is easy until two tills sell the same item

Writing a sale to local storage and pushing it later is a solved problem. Any competent team can build it in a sprint. The reason offline-first systems fail is not the queue — it is the reconciliation, and reconciliation is where the actual business rules live.

Here is the canonical case. A shop has one unit of an item left. The network drops. Two tills, both holding a stock count of one, both sell it. The network returns. The server now has two valid sales for one unit of stock, each with a customer who has already walked out with something.

There is no clever algorithm that resolves this. The stock is gone or it isn't; the software cannot make a second unit exist. What the software can do is make the disagreement visible immediately, attribute it precisely, and give someone the means to fix it. That is the whole job, and teams who go looking for a merge strategy instead of an exception workflow tend to ship something that silently drops one of the two sales.

So the first principle is that sales are facts and stock is a derived opinion. A completed sale is immutable — it happened, money changed hands, a customer has goods. Never let a sync process reject or rewrite one. Stock level, by contrast, is a running calculation over those facts, and it can legitimately go negative. A negative stock position is not a bug; it is the system correctly telling you that reality and your records have diverged. Systems that clamp stock at zero destroy exactly the signal an operations manager needs.

The second principle is that conflicts are routed, not resolved. When the server detects that two devices consumed the same unit, it should raise a specific, actionable exception — this item, these two sales, these two operators, this time window — into a queue a human works through. Compare that to the usual alternatives. Last-write-wins silently discards a real sale. First-write-wins silently discards a different real sale. Both produce a system that is quietly lying, and the lie surfaces weeks later during a stock count nobody can explain.

The third principle is that every record needs enough provenance to reconstruct the sequence. Device identifier, local sequence number, local timestamp, server receipt timestamp, and the version of the price and tax rules that were applied. Wall-clock time alone is not sufficient — tills drift, and one with a wrong date will happily poison an ordering scheme that trusts it. We have seen a device two days behind reorder an entire day's trading.

The fourth is that some operations must simply be refused offline. Refunds against sales the device has never seen. Voids of transactions already settled. Anything crossing a credit limit the device cannot verify. There is a strong temptation to allow everything offline for the sake of a smooth demo, and it is always the wrong call — the cost lands on the operations team weeks later, in a form they cannot trace back to the decision that caused it.

The design question worth asking early is which way you want to fail. You can bias toward availability, letting the shop keep trading and accepting that you will sometimes sell stock you don't have. Or you can bias toward consistency, refusing the sale when the device cannot confirm. For retail, availability is almost always correct — a refused sale is a lost customer, and an oversell is a phone call. For lending or account withdrawal, the answer inverts sharply.

What matters is that it is a decision, made deliberately, per operation, and written down. Most systems we review have never made it. They have a default that emerged from whichever engineer wrote that path first, and it is different in three places.

Offline-first is not a technique. It is an admission that your records and the world will diverge, and a plan for what happens next.