Offline and resilience
The register owns its data. The internet is only for sync.
There is no “offline mode” to switch on: the register always sells from its own database and always uploads through a durable outbox. A dropped line, a killed app, a power cut or a reboot changes nothing about what was sold or what will post.
GUARANTEES
Sellingnever needs the server
Staged datasurvives kill, loss, reboot
Syncexactly once, in order
Postingidempotent, chained, retried
Lookupslocal first, central fallback
What happens to a ticket
From the scan to a posted invoice, every step is durable.
01Scan or tapBarcode, serial, item field, quick button
02Register databaseAppend-only ticket events, hash chain, sequence
03Durable outboxSurvives power loss and reboots; uploads in order
04Central serverIdempotency keys, posting jobs, operations page
05SAP Business OneA/R Invoice and Incoming Payment per ticket
Prices and promotions offlinePrice lists, tax codes, promotions, coupons’ offline policy, rates and banknotes are on the register. A ticket stamps the price and tax version it used.
Rights offlineEffective rights are cached per user, so a cashier signs in with a PIN and a manager approves with a PIN or a card, with no server in sight.
Store hub when the WAN is downRestaurants and multi-register stores can run the server binary in store mode on the LAN to share tables, held tickets and kitchen orders.
Drilled against the real failuresEvery outbox-backed flow has an offline drill: the network dropped mid-upload, the app killed mid-ticket, the power lost before the outbox flushed, the Service Layer down for an hour, a clock set wrong.
Network dropApp killPower lossRebootSAP downClock skewReplayFIFO upload
The guards
Rules that make the guarantee true.
Append-only ticketsEvents are never updated or deleted; voids are marked. A register sequence and a hash chain give every ticket a provable place in history.
Client identityTickets and every mutating event carry a ULID made on the register; the server accepts each once, whatever the retries.
Check-in deadlineA register that has not synced for the configured days warns, then refuses to sell until it checks in, so a lost device cannot run forever.
Clock skewA register whose clock drifts beyond the tolerance is flagged in monitoring and told the next action.
Upgrade in placeA new build re-pulls master data from zero once, replays nothing, and keeps every staged ticket; upgrades are tested from pilot fixtures.
Central fallbackCross-store returns and lookups ask the server when it is there and say so plainly when it is not.
Pull the network cable during the demo.
We encourage it.