#MQTT: The Protocol of IoT and Millions of Devices

MQTT is a lightweight publish-subscribe protocol built for IoT, with a 2-byte header that lets sensors run on a battery for years, and it is the de-facto standard for telemetry at scale.

#What it is

MQTT, or Message Queuing Telemetry Transport, is a publish-subscribe protocol originally built by IBM in 1999 and standardized by OASIS, with the current version at 5.0. It runs on TCP and uses a broker in the middle to route messages between publishers and subscribers who never know about each other.

Think of it as a radio station. The publisher broadcasts to the station without knowing who is listening. Subscribers tune in to the channels they care about. The broker handles distribution. This decoupling is what lets MQTT scale to millions of devices.

#Why it matters

• The fixed header is just 2 bytes, making it suitable for low-power devices and slow networks like 2G.
• Pub/sub separates publisher from subscriber, which scales far better than point-to-point request-response.
• Three QoS levels give flexible reliability: QoS 0 is fire-and-forget, QoS 1 guarantees at-least-once, and QoS 2 guarantees exactly-once delivery.
• Brokers like EMQX and HiveMQ handle millions of concurrent connections on a single cluster.
• It is the de-facto standard in IoT, home automation, industrial telemetry, and SCADA systems. Facebook Messenger even used MQTT for push notifications.

#How it works

A client publishes a message to a topic, which is a hierarchical string separated by slashes, like home/living/temp. Subscribers register interest in topics, and can use wildcards: + matches a single level, and # matches multiple levels. The broker routes each published message to every client subscribed to the matching topic.

MQTT includes two features that solve common IoT problems. Retained messages let the broker store the last message on a topic, so new subscribers immediately receive the latest value without waiting for the next publish. Last Will and Testament lets a client register a message in advance, and if the client disconnects unexpectedly, the broker publishes that will message to notify others, so IoT systems do not need to poll for device status.

#Caveats

MQTT requires a broker, which adds an operational component you must run and monitor. It is pub/sub, not request-response, so it does not replace REST for web APIs. There is no schema, so payload format is up to the parties to agree on beforehand. TLS and authentication become more complex when you are managing millions of devices, and certificate rotation at that scale is a real operational concern.

#Who it's for

MQTT is for anyone building IoT systems, home automation, industrial telemetry, or large-scale messaging where lightweight payloads and massive connection counts matter. It is not the right choice for request-response web APIs.

MQTT is the king of IoT. If you work with sensors, telemetry, or device networks at scale, this is the protocol, but budget for the broker and the operational overhead it requires. Source: https://github.com/eclipse/mosquitto