Exactly-once, on a connection you do not control

The requirement sounds modest: keep working offline. What it actually means is that the client is authoritative for a period you do not choose, and every operation it queued has to land exactly once when it reconnects. Not at least once, which double-charges. Not at most once, which loses a sale.

The mechanism is a client-generated identifier on every operation. The server records what it has already applied, so a replayed batch is recognised rather than reapplied. That is the whole idea, and the difficulty is in the branches: an operation can be new, already applied, or in conflict with something that changed while the device was away. Each arm is a genuinely different outcome and collapsing any two of them produces a bug you will find in a stock count weeks later.

Conflicts are tagged rather than raised as errors. A conflict is information: two people did something reasonable and the system cannot rank them without business context. Tagging keeps the batch moving and puts the decision in front of someone who understands the shop.

The other half is that offline clients are untrusted clients. Offline edits go through a field allowlist, because without one a modified device can write a revenue total directly. And stock decrements are a single guarded operation rather than a read followed by a write, so two tills selling the last box cannot both succeed. That is not defensive coding, it is the only version that is correct under concurrency.