The MQTT pub-sub pattern doesn’t just decouple producers and consumers; it actively obliterates the need for them to even know each other exist.
Imagine a busy marketplace. Producers are vendors shouting about their wares, and consumers are shoppers looking for specific items. In a traditional point-to-point system, each vendor would need a direct line to every shopper interested in their goods, and vice-versa. It’s chaotic, unscalable, and impossible to manage.
MQTT’s publish-subscribe model introduces a central bulletin board, the MQTT broker. Vendors (publishers) post messages to specific "topics" on this board, like "fruit/apples" or "weather/temperature/london." Shoppers (subscribers) express interest in these topics by subscribing to them via the broker. When a vendor posts a message to "fruit/apples," the broker automatically forwards it to all shoppers who have subscribed to "fruit/apples." The vendor doesn’t know who the shoppers are, and the shoppers don’t know who the vendor is. They only know the topic.
Let’s see this in action. We’ll use mosquitto_pub and mosquitto_sub for illustration, assuming a local Mosquitto broker running on localhost:1883.
First, let’s set up a subscriber. We want to know about temperature readings in London.
mosquitto_sub -h localhost -p 1883 -t "weather/temperature/london" -v
The -t "weather/temperature/london" specifies the topic we’re interested in. The -v flag shows the topic along with the message, which is helpful for debugging. Now, this command will just sit there, waiting for messages.
Next, in a separate terminal, let’s publish a temperature reading.
mosquitto_pub -h localhost -p 1883 -t "weather/temperature/london" -m "22.5"
Here, -t "weather/temperature/london" is the same topic, and -m "22.5" is the actual message payload.
Instantly, in the first terminal where mosquitto_sub is running, you’ll see:
weather/temperature/london 22.5
The publisher posted, the broker received, and the subscriber got the message. No direct connection, no prior handshake, just topic-based delivery.
What if we want to subscribe to all weather-related temperatures? MQTT supports wildcards. A + matches a single level, and # matches zero or more levels.
Let’s subscribe to all cities for temperature:
mosquitto_sub -h localhost -p 1883 -t "weather/temperature/+" -v
Now, if we publish to a different city’s temperature:
mosquitto_pub -h localhost -p 1883 -t "weather/temperature/paris" -m "19.0"
The subscriber will receive:
weather/temperature/paris 19.0
And if we publish to London again:
mosquitto_pub -h localhost -p 1883 -t "weather/temperature/london" -m "23.0"
The subscriber gets:
weather/temperature/london 23.0
The power of this pattern is immense. Producers don’t need to know about consumers, and consumers don’t need to know about producers. They only need to agree on the topic names. This allows new producers or consumers to be added or removed dynamically without affecting any other part of the system. A new sensor reporting temperature can start publishing to weather/temperature/berlin, and any existing or future subscriber interested in Berlin’s temperature will automatically start receiving it. Similarly, if a dashboard stops caring about London’s temperature, it can simply unsubscribe, and no one needs to reconfigure the sensors.
The broker itself is the central nervous system. It maintains the list of connected clients and their subscriptions. When a message arrives, it looks up which clients are subscribed to that specific topic (or topics matching wildcards) and forwards the message to them. It handles the complexity of routing and fan-out, ensuring that messages reach all interested parties efficiently. For clients that are temporarily offline, MQTT offers Quality of Service (QoS) levels. QoS 0 is "at most once" delivery (fire and forget). QoS 1 is "at least once" delivery (ensures the message arrives but might be delivered multiple times). QoS 2 is "exactly once" delivery (ensures the message arrives exactly once, but is more complex and resource-intensive).
A crucial aspect often overlooked is the hierarchical nature of MQTT topics, which are dot-separated strings. This structure isn’t just for organization; it’s fundamental to how wildcard subscriptions work. A publisher doesn’t need to know if there are any subscribers for a topic before publishing. It simply sends the message to the broker, trusting that if anyone is interested, they will receive it. This asynchronous, fire-and-forget nature (especially with QoS 0) is what enables extreme decoupling and resilience.
The next logical step after mastering pub-sub is understanding how to manage persistent connections and handle client disconnections gracefully, often involving the concept of "Last Will and Testament" messages.