IoT architecture: devices, protocols and why MQTT is not always the answer

An IoT system has the same pieces as any backend, plus something most backends do not have: thousands of small devices in the field with poor connectivity, limited power and no one nearby to fix them.

The usual layers

1. Devices — sensors and actuators running firmware on constrained hardware.
2. Connectivity — Wi-Fi, cellular, Bluetooth Low Energy, LoRaWAN, Zigbee or wired links, chosen for range, power and cost.
3. Gateways (sometimes) — local hubs that translate protocols, buffer data and keep things working when the internet drops.
4. Ingestion — a broker or endpoint that receives messages reliably at volume.
5. Processing and storage — stream processing, time-series storage and a relational store for device and customer records.
6. Applications — dashboards, alerts, APIs and control interfaces.
7. Device management — provisioning, configuration, monitoring and over-the-air updates.

Choosing a protocol

MQTT is a lightweight publish-subscribe protocol designed for constrained devices and unreliable networks. It keeps connections open, uses small headers, supports different delivery guarantees and lets devices receive commands without polling. It is a strong fit for many device-to-cloud systems.

HTTP/HTTPS is familiar, works through nearly every network and is easy to debug. It is request-response, so it is less natural for pushing commands to devices and heavier for battery-powered hardware. For devices that report infrequently and have reliable power and connectivity, it can be perfectly adequate.

CoAP is designed for very constrained devices and networks, with a REST-like model over UDP.

WebSockets suit browsers and richer devices needing persistent two-way communication.

There is no universal winner. Decide from the constraints: power budget, message frequency, direction of traffic, network quality, and how much your team already knows. A smart-meter fleet and a connected appliance have different answers.

Design for the unreliable edge

• Connectivity will drop. Devices should buffer data locally and send it when they reconnect, with timestamps from the device and an ingestion time recorded separately.
• Messages can arrive late, duplicated or out of order. Make processing idempotent and do not assume order.
• Clocks drift. Treat device time as a claim, and keep server-side time too.
• Bandwidth and cost matter. Cellular data is billed. Batch, compress and send only what you need.
• Plan for backpressure. A burst after an outage should not overwhelm ingestion.

Data modelling

Telemetry is high-volume, append-only and queried by time. A time-series database or well-partitioned table suits it. Device identity, ownership, configuration and customer data fit a relational store. Keep them separate and link by device identifier. Decide retention early: raw data at full resolution is rarely needed forever, so downsample or archive older data.

Updates are not optional

Every device will eventually need a firmware update, to fix bugs or security flaws. Design over-the-air updates from the start: signed images, staged rollouts, health checks after update and a safe rollback if the new firmware fails to boot. Retrofitting this after devices ship is extremely hard.

Provisioning and identity

Each device needs a unique identity and credentials established at manufacture or first boot, and a way to revoke them. Avoid shared credentials across a fleet.

What to take away

Treat an IoT product as a distributed system with unreliable edges. Pick protocols from real constraints, assume messages are late and duplicated, separate telemetry from device records, and design secure over-the-air updates before the first device ships.