IoT & Edge Computing
Edge runtime selection, OTA updates, and offline-first device architectures.
Designing for intermittent connectivity
Edge devices lose connectivity as a matter of routine, not as an edge case. Every write path from a device needs a local queue and idempotent replay — the device buffers locally, and the backend needs to safely accept the same event twice without double-processing it.
OTA updates without bricking the fleet
Over-the-air updates need a staged rollout (canary devices first), a signed-artifact verification step on-device before install, and — non-negotiably — an A/B partition or equivalent rollback path so a bad update doesn't require a truck roll to fix.
- Canary rollout to a small device cohort before fleet-wide push
- Signature verification before any firmware install
- A/B partitions so a failed update auto-rolls-back on boot
Choosing an edge runtime
Constrained microcontrollers (no OS) need a minimal event-loop firmware; Linux-capable edge gateways can run containerized workloads (Balena, K3s) which makes fleet management much closer to standard DevOps; and true offline-first apps need a local-first data layer (e.g. CRDTs or a local SQLite with a sync protocol) rather than assuming the cloud is always reachable.
Working through something like this?
Get a scored blueprint in the Architecture Lab, or talk it through with the Architect Assistant first.