Edge, Mobile and IoT
Architectures where compute sits on devices or near users — sharing the constraints of intermittent connectivity, limited resources and clients you cannot upgrade.
Definition
A family of architectures in which significant work happens outside your data centre: on a phone, on a sensor, in a vehicle, at a point of presence.
The constraints they share
- Connectivity is intermittent. The design must work while disconnected and reconcile afterwards, which makes synchronisation and conflict resolution a core concern rather than an edge case.
- Clients cannot be upgraded on demand. A mobile app from two years ago is still running; a sensor in a field may never be updated. Every server change must be compatible with every version in the wild, which makes backward compatibility a structural property rather than a courtesy.
- Resources are constrained. Battery, memory, bandwidth, processing.
- The fleet is large and heterogeneous. Thousands or millions of devices in different states, on different versions, in different conditions.
- Physical access is limited or impossible, so recovery must be remote and must survive a failed update.
The recurring design decisions
What is decided locally and what centrally. Local decisions work offline and respond immediately; central decisions are consistent and can use more information. Most systems need both, with a clear statement of which is which.
How state converges. Local writes plus intermittent connectivity means conflicts. Options: a single authoritative writer per record, conflict-free data types where the structure allows, or explicit conflict surfacing. Last-write-wins by device clock is the trap — device clocks are unreliable and the losses are silent.
How updates are delivered safely. Staged rollout, verification, and the ability to roll back — on a device you cannot physically reach. A bad update to a fleet is unrecoverable in a way a bad server deployment is not.
What is sent. Bandwidth and battery cost per byte. Aggregate and sample at the device rather than sending everything and filtering centrally.
Failure scenarios
- Designed as though connectivity were continuous.
- A server change incompatible with older clients, which cannot be fixed by deploying.
- A bad update bricking a fleet, with no recovery path.
- Device clocks trusted for ordering or conflict resolution.
- Telemetry unbounded, exhausting battery and data allowance.
Interview question
"What do mobile, IoT and edge architectures have in common that data-centre architectures do not?"