MQTT: How Smart Devices Send Tiny Messages Across the Internet

Picture 50,000 temperature sensors scattered across a city — on bridges, in apartments, on streetlights. Every 30 seconds, each sensor needs to report its reading to a central server. If each sensor opened a full HTTP connection like a web browser, the network would collapse under the overhead. This is exactly the problem that gave birth to MQTT in 1999, and why it now runs on hundreds of millions of IoT devices worldwide.

By the end of this lesson you will be able to: - Explain why MQTT was designed instead of using standard web protocols - Describe the publish/subscribe model and identify its three key roles - Read and construct MQTT topic strings using hierarchies and wildcards - Compare the three Quality of Service levels and choose the right one for a given use case

HTTP — the protocol your browser uses — is built on a request/response model. Every time you want data, you make a request; the server responds. This works well for humans browsing websites, but it is wasteful for constrained devices. A typical HTTP request adds hundreds of bytes of header overhead just to carry a few bytes of sensor data. IoT devices often run on batteries and limited microcontrollers with as little as 64 KB of RAM. They need a protocol that is tiny, efficient, and handles unreliable networks gracefully — like a cellular connection in a moving vehicle or a sensor on an oil platform in rough weather.

MQTT (Message Queuing Telemetry Transport) is a lightweight publish/subscribe messaging protocol created in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper (now Cirrus Link) to monitor an oil pipeline running across a desert via satellite link — a scenario with expensive, unreliable bandwidth and low-power sensors. Unlike HTTP, MQTT does not use direct device-to-device communication. Instead, all messages flow through a central server called a broker. Devices that want to share data publish messages to the broker; devices that want to receive data subscribe to topics on the broker. The broker routes messages to the right subscribers. MQTT became an OASIS open standard in 2014. Today it powers home automation (Home Assistant, SmartThings), industrial monitoring, Amazon AWS IoT, and Facebook Messenger used it internally for mobile push notifications.

Three roles define every MQTT system: The Broker is a server (commonly Eclipse Mosquitto or HiveMQ) that receives all messages and routes them. It decouples publishers from subscribers — neither side needs to know the other exists. Popular cloud brokers include AWS IoT Core and HiveMQ Cloud. Publishers are devices or applications that generate data and send it to the broker under a topic address. A temperature sensor might publish to home/kitchen/temperature every 60 seconds. Subscribers register interest in topic patterns with the broker. A home dashboard app might subscribe to home/+/temperature (the + is a wildcard meaning any single level). Whenever any room sensor publishes, the dashboard receives the message automatically. This decoupled model means you can add new sensors or new consumers without changing anything else in the system.

MQTT messages are addressed using topic strings — slash-separated hierarchies like home/bedroom/temperature or factory/line3/motor/rpm. Wildcards allow subscriptions to multiple topics: + matches one level, # matches any number of remaining levels. Quality of Service (QoS) levels control reliability: QoS 0 — At most once: fire and forget. The message is sent once with no acknowledgment. Fast and low-overhead, best when occasional data loss is acceptable (e.g., frequent sensor readings where the next update arrives soon). QoS 1 — At least once: the message is delivered and acknowledged, but might arrive more than once if the acknowledgment is lost. The receiver must handle duplicates. QoS 2 — Exactly once: a four-step handshake guarantees the message arrives exactly one time. Highest overhead, used for commands where duplicates cause problems (e.g., 'unlock door').