Building for intermittent connectivity
Much of the territory we serve has unreliable networks. Treating that as the normal case, rather than the exception, changes the architecture.
Placeholder article. Replace with your own editorial before publishing.
A ward office loses its link for six hours. A collection agent works a village with 2G on a good day. A bus drives through forty kilometres of dead zone.
If your design assumes connectivity and degrades when it is absent, these are outages. If your design assumes intermittency, they are ordinary Tuesdays.
Principles we apply
Local-first writes. The device records the transaction locally and acknowledges the user immediately. Sync is a background concern.
Idempotency keys everywhere. Every operation carries a client-generated identifier. Replay after reconnect is safe by construction, which matters a great deal when money is involved.
Explicit states, never ambiguous ones. The interface says queued, confirmed, or failed. It never says submitted and leaves the operator guessing. Ambiguity is what produces a customer handing over cash for nothing.
Conflict rules decided in advance. When two devices edit the same record offline, the resolution rule is a business decision, made during design — not whatever the sync library happens to do.
Gaps modelled as gaps. A vehicle that stops reporting is not a stopped vehicle. Telemetry systems that conflate the two generate alerts nobody trusts, and an alert nobody trusts is worse than no alert.
The payoff
Systems built this way are also better on good networks. Local-first writes feel instant. Idempotent operations survive retries. The constraint improves the design.
- Engineering
- IoT
- Mobile