MQTT for IoT — What It Is and Why It's the Right Protocol

When you build your first IoT project, you eventually need a way for devices to communicate — sensors publishing data, controllers receiving commands, dashboards displaying state. The naive approach is HTTP: the device makes a REST call, the server receives and processes it. This works for simple cases.

But HTTP has characteristics that make it poorly suited to IoT at scale: it's connection-oriented (each request requires a new connection setup on most implementations), relatively verbose in its headers, and fundamentally request-response rather than event-driven.

MQTT (Message Queuing Telemetry Transport) was designed for exactly the constraints IoT devices face: low bandwidth, high latency, unreliable networks, and devices with limited power and memory. It's become the de facto standard for device communication in IoT systems.

The publish-subscribe model

MQTT uses a publish-subscribe architecture mediated by a broker. Devices don't communicate directly with each other.

Publishers send messages to topics: a message published to "sensors/temperature/kitchen" is published to that topic string. The publisher doesn't know who (if anyone) is listening.

Subscribers register interest in topics with the broker: "send me everything published to sensors/temperature/#" (the # wildcard matches any continuation). When a publisher sends to a matching topic, the broker delivers the message to all current subscribers.

The broker is the intermediary — it receives all messages and routes them to subscribers. Mosquitto is the most common open-source MQTT broker; many cloud IoT platforms (AWS IoT, Azure IoT Hub, Adafruit IO) provide MQTT endpoints.

This decoupling of publishers from subscribers has practical benefits: you can add subscribers (new dashboard, logging service) without changing the devices. You can add devices without changing the processing backend. The architecture scales cleanly.

QoS levels

MQTT defines three quality-of-service levels for message delivery:

QoS 0: at most once. The message is sent and forgotten. No acknowledgement, no retransmit. Fast, minimal overhead, but messages can be lost if the connection drops.

QoS 1: at least once. The broker acknowledges delivery. If no acknowledgement is received, the message is retransmitted. Messages are guaranteed to arrive but may arrive multiple times.

QoS 2: exactly once. A four-way handshake ensures the message is delivered exactly once, never duplicated. Highest overhead, used where duplicate delivery would cause problems (command execution, for example).

For most sensor telemetry (temperature readings, status updates): QoS 0 is fine. Occasional lost readings don't matter. For commands that trigger actions: QoS 1 or 2 is appropriate.

The retained message and last will

Two MQTT features that matter for IoT:

Retained messages: a message published with the retained flag causes the broker to store it. New subscribers immediately receive the last retained message on that topic. This is useful for state topics — "device/status" with a retained message means any new subscriber immediately knows the current device state.

Last will and testament (LWT): when a device connects, it can register a "last will" message — a message that the broker will publish to a specified topic if the client disconnects unexpectedly (network failure, power loss). This gives the rest of the system immediate notification of device loss. "device/kitchen-sensor/status" with LWT payload "offline" lets your dashboard immediately know when a sensor drops off the network.

For a well-implemented IoT system: use retained messages for state, use LWT for device presence, and use QoS 1+ for commands.