The short version
MQTT keeps messages small and lets devices exchange data through a broker. Its delivery settings let you balance reliability with network cost.
A small protocol with a useful job
Choosing a communication protocol shapes how an IoT system exchanges data. MQTT is a common choice because it is lightweight and suited to devices with limited resources or unreliable connections.
This article is part of our series on the services we use in IoT projects. It covers how MQTT works, the choices behind its delivery guarantees and where engineering experience matters.
Devices publish. The broker connects
MQTT uses a publish-and-subscribe model. A device sends a message to a named topic on a broker. Other devices or applications subscribe to the topics they need, and the broker forwards matching messages.
Publishers and subscribers communicate through topics on the broker.
Designed for limited connections
MQTT keeps communication overhead small. That makes it useful on networks with little bandwidth or long delays, and on devices where processing power and energy are limited.
The sender does not need to know the reader
Publishers know which topic to use. Subscribers know which topics interest them. They do not need direct connections to one another, so you can add a new consumer without changing each device that produces the data.
Choose the delivery guarantee you need
MQTT offers three Quality of Service levels, usually shortened to QoS. Each balances delivery assurance against communication overhead.
QoS 0: at most once
The sender publishes without waiting for an acknowledgement. A message can be lost, which can be acceptable when the next sensor reading will arrive shortly.
QoS 1: at least once
The receiver acknowledges delivery. A message may arrive more than once, so the application needs a safe way to handle duplicates.
QoS 2: exactly once
A four-step exchange prevents duplicate delivery between the MQTT sender and receiver. It adds communication overhead, so choose it when the product needs that guarantee.
| Level | Delivery | Application trade-off |
|---|---|---|
| QoS 0 | At most once | Allow for missing messages. |
| QoS 1 | At least once | Handle possible duplicates. |
| QoS 2 | Exactly once | Account for the extra exchange. |
These guarantees apply between an MQTT sender and receiver. The broker negotiates delivery to subscribers separately; application-level processing still needs its own design. See the OASIS MQTT specification for the protocol details.
Three questions before choosing
- How critical is data consistency to the product and the business?
- Can the back end fill gaps when a reading is missing?
- Can it process the same message again without changing the result?
That last property is called idempotency. The answers help you choose a QoS level that fits the product, its infrastructure and its budget. Using the highest level everywhere can spend network resources without adding useful protection.
Give device status some context
Retained messages
A broker can retain the latest retained message for a topic. A new subscriber can receive that value when it subscribes, instead of waiting for the next update.
Last Will and Testament
A client can register a message for the broker to publish if the connection ends unexpectedly. Other parts of the system can use this to notice that a device has gone offline.
The decisions around the protocol
Choosing MQTT is the beginning. Configuration, integration and maintenance determine how well it serves the product.
Configuration and tuning
QoS, retained messages and Last Will settings should reflect the application. The right combination depends on what a reading means, how often it arrives and what happens when it is late.
Integration
The broker needs to fit the rest of the system: existing protocols, databases and cloud services. The team defines how messages become useful data and where each component’s responsibility begins.
Security
Authentication, authorisation and encryption need deliberate implementation in both the application and the platform. A clear division of responsibility helps protect the path between publishers, the broker and subscribers.
Scale and maintenance
As the deployment grows, broker load grows with it. The system needs capacity planning, performance monitoring and a way to investigate failures. Supporting services used in our work include AWS IoT Core, EMQX, HiveMQ and RabbitMQ.
Choose for the product
MQTT is useful because of its small footprint, publish-and-subscribe model and flexible delivery guarantees. The engineering work is choosing the settings, infrastructure and application behaviour that make those features useful for your devices.
