Edge-First IoT Architecture: When Centralised Cloud is the Wrong Choice

Edge versus cloud is usually framed as an architectural preference. It is not. For any given workload the placement is determined by four constraints — latency, bandwidth, availability and data sovereignty — and in most industrial systems at least one of them decides the answer before anyone expresses a preference.

Start with the bandwidth arithmetic, because it is often disqualifying

Teams design a telemetry schema, deploy a pilot with twenty devices, and scale to four thousand without recomputing the aggregate. The calculation takes a minute and frequently rules out cloud-first entirely.

A modest example: 500 machines, 40 signals each at 10 Hz, 12 bytes per sample as compact binary. That is 200,000 samples/s and roughly 19 Mbit/s sustained before overhead — over a site uplink shared with everything else the plant does, continuously, forever. The same data as JSON over individually-published MQTT messages is comfortably five times that.

The resolution is not compression. It is deciding what leaves the site. High-rate signals are consumed locally by the control and analytics that need them; what crosses the uplink is features, aggregates and exceptions. A vibration channel sampled at 20 kHz for envelope analysis does not need to leave the building — the band energies and detected defect frequencies do, at a rate four orders of magnitude lower.

The latency budget, decomposed

Round-trip latency to a regional cloud is 20–80 ms in good conditions and unbounded in bad ones. Whether that matters is a question about the control loop, not about preference, and the honest way to settle it is to write down every term.

Availability: the site must run when the link does not

An industrial site cannot stop producing because a WAN link is down. Any architecture where a cloud dependency sits in the production path has made connectivity a single point of failure for the plant, and that is rarely a trade anyone would accept if it were stated plainly.

Store-and-forward is therefore mandatory rather than a resilience nicety, and the buffer must be sized against a realistic outage, not a typical one.

Two behaviours must be designed alongside the buffer. What happens when it fills — dropping oldest, dropping lowest-priority, or refusing ingest — is a decision with process consequences, and defaulting to whatever the broker does is how sites discover they lost their compliance record. And the drain rate after reconnection must be rate-limited, or four thousand devices reconnecting simultaneously will saturate the recovered link and produce a second outage from the recovery of the first.

Protocol choice: MQTT, OPC UA, and the thing that reconciles them

OPC UA carries a rich, self-describing information model and is the right vocabulary for machine data — it says what a value means, not merely what it is. MQTT is a lightweight publish-subscribe transport that traverses NAT and firewalls cleanly and scales to large fan-out. They are not competitors, and the common architecture uses both.

Plain MQTT has one significant deficiency for industrial use: it is stateless about liveness. A subscriber cannot distinguish a device that is reporting an unchanging value from one that stopped reporting an hour ago. Sparkplug B fixes exactly this, and the fix is why it is worth adopting.

• Birth certificates: on connect, a device publishes its complete metric set with types and aliases, so late-joining consumers get full state without polling.
• Death certificates: registered as an MQTT will, so the broker announces the device's loss immediately rather than leaving consumers to infer it from silence.
• Sequence numbers on every message, making gaps detectable rather than silent.
• Report-by-exception with defined state semantics — a consumer always knows whether the last value it holds is current or stale.

Above the protocol, the organising idea worth adopting is a unified namespace: a single hierarchical topic structure — enterprise, site, area, line, cell — that every system publishes into and consumes from. It replaces point-to-point integrations, whose count grows quadratically with system count, with a single hub each system connects to once. That is the difference between an integration estate you can extend and one you eventually replace.

Running models at the edge

Edge inference hardware is constrained in memory bandwidth and power far more than in raw arithmetic. Post-training INT8 quantisation typically yields around 4× memory reduction and 2–4× throughput improvement, and on well-behaved vision models the accuracy cost is under a point of top-1 with a properly chosen calibration set.

The calibration set is the part that gets rushed. Quantisation ranges derived from a few hundred convenient images will not cover the activation distribution the model sees at 3 a.m. under different lighting, and the resulting accuracy loss is both larger and harder to diagnose than the quantisation itself. Calibrate on data sampled across shifts, seasons and product variants, and validate the quantised model — not the float one — against the acceptance criteria.

The decision, stated as a rule

Put it at the edge if the control loop closes faster than the network's p99.9 permits, if the raw data rate exceeds what the uplink can sustainably carry, if the process must continue through a link failure, or if the data cannot legally leave the site. Put it in the cloud if you need to correlate across sites, train on aggregated history, or run workloads whose peak far exceeds their mean. Most real systems do both, and the architecture that ages well is the one where that split was decided by these constraints rather than inherited from whichever platform was procured first.