Should the till keep trading when the line drops?
Tills fall into two camps. Offline-first systems queue tickets, payments and fiscal events on the terminal so service never stops. Online-only systems lean on a fast line and buy simplicity and cheaper hardware with it. Here is the honest split.
Offline-first till
The terminal carries its own database (IndexedDB or SQLite). Orders, payments and Z-reports queue on the device and sync quietly once the line returns.
- Sales do not stop: dead modem, cut fibre, storm on the line, the till still rings
- Fiscal pairing is local, so receipts print even with the back end unreachable
- The conflict rule is stated up front (usually server wins), so reconciliation is predictable
- Days of autonomy, typically 24 to 72 hours, which covers realistic outages
- Engineering cost is real: local store, queue, sync and conflict resolution
Online-only till
The terminal is a thin client over the network. Every order is a round trip, and nothing is held on the device beyond what is on screen.
- A smaller bundle and cheaper hardware per terminal
- A simpler build: no local store, no sync, no conflict rule to reason about
- Faster rollout, since a server-side change reaches every terminal at once
- Less engineering spent on plumbing, so more of it goes to the layers guests notice
- Needs a reliable line, and a plan for the mornings it is not
When each one makes sense
Take option A when
Offline-first matters when every minute of downtime is revenue you never get back or a queue you cannot recover: fast casual at lunch, festivals, food trucks, anywhere the signal is patchy. It matters again in countries where the fiscal device must keep signing receipts through an outage, because losing the line must not mean losing compliance.
Take option B when
Online-only is the right pick when the site has a reliable line with a mobile fallback, when a short outage is survivable (fine dining can take orders on paper for ten minutes), and when you would rather spend the engineering budget on what the guest sees than on resilience plumbing.
Frequently asked
How long should an offline-first till survive without a line?
Most systems in production target 24 to 72 hours of autonomy, covering order entry, taking payment, fiscal signing where it applies and the printer flow. Past 72 hours the local database grows enough that reconciliation needs care, which is why that is usually where the cap sits.
Can offline-first work for card payment?
Yes for chip-and-PIN terminals that handle the card-network handshake locally and authorise small amounts inside their risk limits. No for methods that are online by definition, such as instant bank transfer and some wallet flows. Most setups take card up to the terminal's local ceiling and queue the settlement record.
What happens to the kitchen display during an outage?
If the kitchen screen sits in the same offline-first cluster as the till, tickets stay readable because they were written to local buffers as the till placed them. If the screen is online-only while the till is not, the pass goes dark mid-outage and the kitchen falls back to printed dockets.
Architecture comparisons
Service starts at six.
Are you ready?
A live demo, thirty minutes. No slides: we build a scenario from your own restaurant, answer what you ask and talk pricing straight.