Should your POS keep working when the line drops?
Restaurant POS systems split into two camps. Offline-first systems queue tickets, payments and fiscal events locally so service never stops. Online-only systems lean on a fast internet line and gain simplicity and cheaper hardware in return. Here is the honest split.
Offline-first POS
The terminal carries a local database (IndexedDB or SQLite). Orders, payments and Z-reports queue locally and sync silently when connectivity returns.
- Sales never stop — modem dead, fibre cut, storm on the line, the till still rings
- Fiscal device pairing is local — receipts print even when the back-end is down
- Conflict policy is explicit (typically server-wins) so reconciliation is deterministic
- Multi-day autonomy (typically 24–72 hours) covers most realistic outages
- Engineering effort: significant. Local data store, queue, sync, conflict resolution
Online-only POS
The terminal is a thin client over the network. Every order is a round-trip; nothing is held locally beyond UI state.
- Smaller bundle, cheaper per-terminal hardware
- Simpler architecture — no local store, no sync logic, no conflict policy
- Faster feature rollout — server-side changes hit every terminal immediately
- Lower engineering investment for the vendor — more budget for higher-value layers
- Requires a reliable internet line and a fallback plan for outages
When each makes sense
Pick option A when
Offline-first matters when every minute of downtime maps to lost revenue or a queue you can't recover (fast casual at lunch peak, festivals, food trucks, anywhere with patchy connectivity). It also matters in countries where the fiscal device must keep signing receipts during an outage — losing connectivity must not lose compliance.
Pick option B when
Online-only is the right pick when your venue has reliable internet (fibre + 4G fallback), a brief outage is operationally acceptable (e.g. fine-dining where you can take orders on paper for ten minutes), and you would rather spend the engineering budget on features the customer sees rather than on resilience plumbing.
Frequently asked
How long should an offline-first POS survive without internet?
Most production offline-first systems target 24–72 hours of autonomous operation, including ticket entry, payment capture, fiscal signing where applicable, and printer flow. Beyond 72 hours the local DB grows enough that reconciliation needs care; that is usually the right cap.
Can offline-first work for card payments?
Yes for chip-and-PIN terminals that handle the card-network handshake locally and authorise small amounts within risk limits; no for online-only payment methods (instant bank transfer, certain wallet flows). Most offline-first setups support card payment up to the terminal's local-auth ceiling and queue the settlement record.
What happens to the kitchen display during an outage?
If KDS runs in the same offline-first cluster as POS, tickets stay readable: they were written to local sync buffers when the POS placed them. If KDS is online-only and POS is offline-first, the KDS goes dark mid-outage and the kitchen falls back to printed tickets.