Offline-first POS architecture for Jordanian restaurants: a reference
Whitepaper · RAWA Engineering · rawaerp.com · measurements and scripts: github.com/rawaerp/jordan-restaurant-pos-benchmark
Problem
A restaurant's busiest hour is the one it can least afford a frozen screen. In Jordan the connection is usually good but not perfect, and the cost of a stall is concentrated in a few expensive hours. Where a POS commits a sale decides whether an outage is a non-event or a lost evening.
Three architectures
| Cloud-only | Legacy desktop | Offline-first (RAWA) | |
|---|---|---|---|
| First commit of a sale | Cloud, after a network round trip | Local DB on the till PC | Local DB on the device, synced after |
| Measured commit latency* | round trip 135–192 ms median (lower bound) | SQLite write 5.5 ms, read 0.09 ms | IndexedDB write 2.3 ms, read 0.9 ms |
| Internet outage | Selling stops | Selling continues | Core selling loop continues |
| Multi-branch, backup | Native | Weak | Native via sync |
*Measured 2026-11-09 on one Windows laptop, desktop Chrome, a consumer connection in Jordan; 2.6 KB sale record; raw data and reproducible scripts in the benchmark repository. These show orders of magnitude, not a claim about any named product — measure on your own device.
What "offline" must mean
Three levels exist: read-only (menu visible, cannot sell), sale-only (sale completes, printing needs the cloud), and full selling loop — sale, payment record, receipt, kitchen ticket — with no internet, followed by a sync that loses and duplicates nothing. Only the third survives a real outage. Features that inherently need a remote service (JoFotara submission, online orders, cloud reports) queue or wait; claiming otherwise would be untrue.
Design rules
- Local-first writes. Menu, prices, taxes and cashier permissions live on the device; the network is an optimisation, not a dependency.
- Printing without the internet. Receipt and kitchen printers sit on the LAN (TCP 9100) or USB; routing prints through the cloud makes "offline" false.
- Idempotent sync. Each sale carries a client-generated id; the server accepts it once, so a half-finished upload cannot create a duplicate.
- Monotonic counters. Invoice numbers and the e-invoicing counter stay ordered across devices that were offline.
- Honest status. The screen says "offline — N sales waiting to sync"; silent offline modes are how missing sales are found at month-end.
Acceptance test (10 minutes, any system)
Disconnect the router's internet cable · ring 20 mixed sales and print every receipt and a kitchen ticket · close and reopen the app midway · reconnect · compare the day report with your tally: 0 missing, 0 duplicated. Full protocol (six scenarios) and result template: github.com/rawaerp/jordan-restaurant-pos-benchmark.
Result
RAWA's POS commits to a local database first and syncs behind it, so a sale completes in the time it takes to tap; the cloud holds accounts, inventory and reports. Reference: https://rawaerp.com/guide/offline-pos-why
Common questions
What does offline-first mean for a POS?
A sale is committed to a database on the device first and synced to the cloud afterwards, so the selling loop (sale, payment record, receipt, kitchen ticket) continues without internet; features that need a remote service wait for connectivity.
How much faster is a local save than a cloud call?
In our measurements (one Windows laptop, Chrome, Jordan, 9 November 2026) a 2.6 KB sale record is written to IndexedDB in a median 2.3 ms, while a round trip to a trivial cloud endpoint takes a median 135 ms in a browser and 192 ms with curl.
How can I test any POS for offline behaviour?
Disconnect the router's internet cable, ring 20 mixed sales, print every receipt and kitchen ticket, close and reopen the app midway, reconnect and compare the day report: zero missing, zero duplicated.