All blogs

Engineering

One ledger, many tills: how offline-first selling works

The network will fail on a Saturday night. Here's the design that lets every register keep ringing anyway, and why the numbers still agree in the morning.

DM

Daniel Mensah

Engineering · · 7 min read

Every point-of-sale system gets tested by the same exam, and the exam is always scheduled for peak trade: the internet dies with a queue at the counter. What happens next is the most honest description of the system's architecture you'll ever get.

A cloud-first till stops. An offline-first till keeps ringing. The difference isn't a feature flag. It's where the system believes the truth lives.

The ledger, not the database

Stocked treats everything that happens in a shop (a sale, a delivery, an adjustment, a transfer) as an entry in an append-only ledger. Nothing edits stock in place; the current number for any SKU is just the sum of its history. That one decision does most of the work, because ledger entries have a property that database rows don't: they merge.

Each register writes sales to its own local ledger first, instantly, whether or not the network exists. Sync is then just the boring job of shipping entries upstream and pulling everyone else's down.

What happens when the line drops

A register that loses the network changes exactly one thing: its queue grows instead of draining. Sales still print, payments on standalone terminals still clear, stock still draws down locally. The register shows 'offline — 2 queued' and nobody at the counter cares.

When the line returns, queued entries replay upstream in order, tagged with the register that wrote them and an idempotency key so a flaky reconnection can't double-post a sale. Two registers selling through an outage merge cleanly because sales never conflict. They only accumulate. The only genuine conflict in inventory is two people manually adjusting the same SKU while apart, and that surfaces for a human to resolve rather than being silently overwritten.

The morning after

The test of the design isn't the outage. It's the report the next day. Four network failures in a month should read as four footnotes in the audit log, not four gaps in the revenue chart. One bar customer of ours put it best: the line dropped mid-service on a Saturday, and the only person who noticed was the router.

Share this post

Stocked is the system these notes are written from. Start free or read more from the blog.

Read next

All posts