← All articles

Offline-First Sync, and Why the Counter Should Never Wait for the Internet

Updated 7 July 2026 · 8 min read

A lot of pharmacy software still treats the internet as a requirement. Open the billing screen and it phones a server; the connection hiccups and the spinner hangs while a customer waits. In 2026 that's a design choice, not a limitation — and the wrong one for a shop. This is how DravyaOS is built the other way round: every action lands instantly on the device in front of you, and the network's job is only to catch the other devices up in the background.

The counter can't depend on a good connection

Indian retail runs on patchy links — a dropped broadband line, a dead SIM, a power cut that takes the router but not your laptop's battery. If billing needs a round-trip to a server for every keystroke, all of that becomes your problem at the exact moment a customer is standing there. The right architecture removes the dependency entirely: the app should be fully usable with the cable unplugged, and syncing is a background nicety, never a gate on making a sale.

Local-first: your data lives on the device

In DravyaOS the source of truth is a database on your own machine — a local SQLite store the app reads and writes directly. When you save a bill, add a medicine, or record a payment, it's written to that local database and the screen updates immediately, with no network in the path. There's no "saving…" spinner waiting on a server on the other side of the country, because there's nothing to wait for. The write already happened, right here.

That single decision is what makes the app feel fast. "Speed" in most cloud apps is really network latency dressed up — a few hundred milliseconds of round-trip on every action. Remove the round-trip and the interface moves at the speed of the machine, which is to say instantly. It's also what makes it genuinely offline: if there's no source but the local one, losing the internet changes nothing about how the app works.

Sync happens after, in the background

So where does the server come in? Every local change is also written to an outbox — a queue of "here's what changed." Whenever a connection is available, the app quietly pushes that queue up and pulls down whatever the other devices have done since. You never trigger it or wait on it; a small status shows pending, syncing, synced, or offline so you can see it working, but the billing never blocks on it. Go offline for a day, sell all day, and the moment you're back online the day's work flows up on its own.

Cross-device should be the norm, not an add-on

A modern shop isn't one PC. It's the billing machine at the counter, a second terminal at the back, the owner's phone checking a balance from home. All of them should show the same data without anyone exporting a file or emailing a backup. In DravyaOS, sign in on any device with your organization code and it pulls your whole organization's data down and joins the same live set — the counter PC and the phone in your pocket are looking at one shared truth, each still fully functional on its own if the link drops.

The hard part: merging two edits without losing one

The moment two devices can both write offline, you have the real engineering problem: the counter marks an invoice paid while, out of signal, the back office edits the same invoice's discount. Both come online. Whose change wins — and does the other one vanish? Getting this wrong silently loses data, which for a pharmacy is unforgivable.

DravyaOS stamps every change with a hybrid logical clock — a timestamp that stays correctly ordered even when two devices' wall clocks disagree, so changes merge in a consistent order on every device rather than depending on who synced first. Related records are applied in dependency order (a payment never lands before the invoice it belongs to), and when one change does overwrite another, the earlier version isn't thrown away — it's logged as a conflict you can review and restore with one click. The default is automatic and correct; the escape hatch is there for the rare case you want to look.

Staying compatible while every device updates on its own

Offline-first has a second, subtler challenge: devices update on their own schedule, so at any moment one may be a version or two behind another. If a newer device sends data an older one doesn't understand, the naive outcome is a stalled sync. DravyaOS is built to expand, never break — new data shapes are added in a backward-compatible way, a behind device simply skips what it doesn't yet know and picks it up cleanly after it updates, and a genuine version mismatch produces a clear "please update" rather than silent corruption. Sync keeps flowing across a fleet that's never perfectly in lockstep.

Why this is the baseline now

Local-first databases, background sync, and clean multi-device merges aren't exotic anymore — they're the established way to build software that has to work in the real world of dropped connections and shared counters. For a pharmacy the payoff is concrete: billing that never freezes because the internet did, data on every device without a manual backup, and no edit quietly lost when two people work at once. That's not a premium feature. In 2026 it's the floor, and it's what DravyaOS is built on — free.

Related reading: how to make a GST-compliant medical bill, and choosing genuinely free pharmacy software.