The postal analogy
Imagine instead of mailing letters directly to specific people, you mail them to a post office with a label on them (“weather-updates” or “front-door-camera”). Anyone who wants that kind of mail tells the post office “sign me up for weather-updates.” The post office forwards every letter with that label to everyone who signed up.
Nobody needs to know who else is involved. The sensor doesn’t know or care what’s reading its data. The dashboard doesn’t know or care which sensor sent it. They both just talk to the broker.
That’s MQTT.
The three players
Publisher: A device that has something to say. A sensor measuring soil moisture, say. It doesn’t send data to any specific place, it just “publishes” it under a label (called a topic), like farm1/field3/moisture.
Broker: The post office (syndicator). A small piece of software (running on a server) that receives all these labeled messages and hands them out to whoever wants them.
Subscriber: Anyone who told the broker “I want everything labeled farm1/field3/moisture.” Could be a dashboard, an app, another device, doesn’t matter. The broker just forwards it to them.
Why it’s popular for IoT
Lightweight: Tiny messages, tiny code footprint. Matters when your “computer” is a $2 chip running on a battery in a field somewhere way out west.
Works on flaky connections: Devices can drop offline and reconnect without everything breaking. It even has a feature where the broker can announce “hey, this device just went silent” (called a “last will” message). This is handy to know when a sensor died vs. is just quiet.
One-to-many for free: One sensor’s reading can go to five different subscribers (a dashboard, a logger, an alert system) without the sensor doing any extra work.
From whence it came…
MQTT’s origin story is actually a nice illustration of why it’s built the way it is. It was created in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper (then Eurotech, now Cirrus Link). The job: Monitor oil pipelines running through remote desert terrain.
Think about what that environment actually looks like:
Bandwidth is precious and expensive. Existing protocols like HTTP have a lot of overhead: headers, handshakes, verbose text. On a satellite link, every byte costs money. MQTT needed a minimal header (as small as 2 bytes) and a binary format instead of chatty text.
Connections are unreliable. Desert satellite links drop out. A protocol that assumes a stable connection (like plain TCP request/response) falls apart here. MQTT was built to handle disconnection and reconnection gracefully, and to know the difference between “device is quiet” and “device is dead” (the last-will-and-testament feature I mentioned earlier came directly from this need).
Devices cannot afford complex logic. The embedded controllers on pipeline equipment in 1999 were not powerful. The protocol had to be simple enough to implement on constrained hardware with a small code footprint and minimal processing.
Tightly coupled systems create bottlenecks. With sensors scattered everywhere reporting to a control room, you don’t want every sensor hard wired to know exactly where to send its data. The publish/subscribe model decouples that. This is where the “post office” analogy came from.
The name itself stood for “MQ Telemetry Transport” — the “MQ” borrowed from IBM’s MQSeries messaging product line. Today the spec just says the initials don’t officially stand for anything anymore.
It stayed mostly proprietary (internal) until IBM released it royalty free around 2010. Then it went to OASIS as an open standard in 2013, which is when it really took off for general IoT use, way beyond its oil pipeline origins. The boom in cloud computing gave it the next boost. Now it is almost ubiquitous in IoT.
Every core design decision; small messages, pub/sub, connection resilience, traces straight back to “how do we reliably get sensor data across a desert on a lossy link without spending a fortune.”
