Explained - Message Queuing Telemetry Transport (MQTT)

Codelooru: NAT

Ever wondered how your smart thermostat "talks" to your phone, or how a sensor on an oil pipeline sends data thousands of miles away? Chances are, MQTT is behind it.

What is MQTT?

MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol designed to send small packets of data between devices — even over slow, unreliable, or low-bandwidth networks. Think of it as a postal system optimised for postcards, not packages. Fast, lean, and works even when connectivity is spotty.

Originally developed in 1999 by Dr. Andy Stanford-Clark (IBM) and Arlen Nipper (Eurotech) to monitor remote oil pipelines via satellite, MQTT has grown into one of the foundational protocols of the modern Internet of Things.

The big idea: publish and subscribe

MQTT doesn't work like a typical web request (ask → get a response). It uses a publish-subscribe model — more like a bulletin board system where senders and receivers never need to know about each other directly.

Temp sensor Smart lock Motion sensor Publishers MQTT Broker Routes by topic Phone app Dashboard Alarm system Subscribers

Publishers send to the broker; the broker routes each message to all matching subscribers

A sensor publishes a reading on the topic home/livingroom/temperature. Any device subscribed to that topic — your phone app, a dashboard, a smart thermostat — instantly receives it. No device needs to know the others exist.

How a message flows

Here's the step-by-step journey of a single message, from the moment a sensor takes a reading to when a subscriber receives it.

1. Connect Device connects to broker 2. Subscribe Client picks topics 3. Publish Sensor sends a reading Broker Matches & routes 4. Deliver Broker pushes to matches 5. Receive Subscribers get message

A message's journey: connect → subscribe → publish → route → receive

Topics: the addressing system

Topics are simple strings that act like channels. They're hierarchical, using / as a separator. Subscribers can use wildcards: home/livingroom/# catches every sensor in the living room. home/+/temperature catches temperature from every room at once.

home/ livingroom/ kitchen/ bedroom/ temperature humidity light motion

Topic hierarchy — subscribers can target one leaf or use wildcards to catch a whole branch

Quality of Service (QoS)

MQTT gives you three levels of delivery guarantee so you can trade reliability against speed depending on what matters for your use case.

QoS 0 At most once Fire and forget QoS 1 At least once Acknowledged, may duplicate QoS 2 Exactly once 4-step handshake, precise

Choose QoS based on how critical the message is vs how much overhead you can afford

Two clever features: retained messages and last will

Retained message Sensor Broker stores last msg New device subscribes later Gets last value immediately Last will & testament Device registers LWT Broker Device drops unexpectedly Publishes LWT msg alerts other devices

Left: retained messages give late subscribers immediate state. Right: LWT lets the broker alert others when a device drops.

Retained messages mean the broker stores the last value on a topic. A new device subscribing gets that value instantly rather than waiting for the next publish — great for current status like temperature readings.

Last Will and Testament (LWT) lets a device pre-register a message with the broker at connect time. If it disconnects unexpectedly, the broker automatically publishes that message — so the rest of the system knows something went wrong.

Security

MQTT is intentionally lean — security is layered on top deliberately. TLS/SSL encrypts data in transit. Username/password or X.509 certificates control who can connect. Topic-level authorisation restricts which clients can publish or subscribe to which channels. The key thing to know: none of this is on by default, so it must be explicitly configured in production.

Real-world use cases

Smart home Industrial IoT Healthcare MQTT Broker Smart cities Connected cars Agriculture

MQTT sits at the centre of many industries — all talking through a shared broker

How MQTT compares to other protocols

Protocol Model Overhead Best for
MQTTPub/SubVery low (2 byte min)IoT, constrained devices
HTTPRequest/ResponseHigh (KB headers)Web APIs
CoAPRequest/ResponseLowLow-power IoT
AMQPPub/SubModerateEnterprise messaging

Challenges to watch out for

  • The broker is a single point of failure — production deployments need clustering or failover
  • Security must be explicitly configured — it's not built into the protocol itself
  • Topic management at scale takes discipline; large systems can end up with thousands of disorganised topics

The bottom line

MQTT is a deceptively simple protocol that enables remarkably powerful communication. Its publish-subscribe model, minimal footprint, and flexible reliability levels make it a natural fit for any system where many devices need to share data efficiently — from a single smart home to a city-wide sensor network.

As the number of connected devices in the world continues to grow into the tens of billions, protocols like MQTT aren't just useful — they're essential infrastructure.

Want to try it yourself? Check out mqtt.org for the spec, and open-source brokers like Mosquitto, or cloud options like AWS IoT Core, HiveMQ, or EMQX to get started.



×