MQTT GUIDE
3 min readMQTT Publish/Subscribe Explained
MQTT uses a publish/subscribe model: clients publish messages to named topics on a broker, and the broker delivers each message to every client subscribed to a matching topic. Publishers and subscribers are decoupled — they interact only through topics, never directly. The three core operations are PUBLISH, SUBSCRIBE, and UNSUBSCRIBE.
Publish/subscribe (pub/sub) is the messaging model at the heart of MQTT. Instead of clients calling each other directly, they exchange messages through a broker: publishers send to topics, subscribers register interest in topics, and the broker delivers each message to every matching subscriber. For the bigger picture of the protocol, see what MQTT is.
How publish/subscribe works
A client tells the broker which topics it wants with a SUBSCRIBE; the broker confirms with a SUBACK. When any client sends a PUBLISH to a matching topic, the broker forwards a copy to each subscriber. When a client no longer wants a topic, it sends UNSUBSCRIBE. Publishers and subscribers never talk to each other — the topic is the only thing they share.
The three operations
| Operation | Sent by | What it does | Broker reply |
|---|---|---|---|
PUBLISH |
Any client | Sends a message to a topic | PUBACK / PUBREC (QoS 1/2) |
SUBSCRIBE |
Subscriber | Registers interest in one or more topic filters | SUBACK |
UNSUBSCRIBE |
Subscriber | Cancels one or more subscriptions | UNSUBACK |
Why pub/sub scales
The decoupling is what makes the model efficient for IoT:
One publish can fan out to thousands of subscribers, and a subscriber can receive from thousands of publishers, all without any of them being aware of the others.
Publish/subscribe in TBMQ
TBMQ matches every PUBLISH against subscriptions held in an in-memory topic trie, so match cost scales with a topic’s depth rather than the total number of subscriptions, and one publish fans out to all matching subscribers. For load-balanced consumption — each message to only one member of a group — TBMQ also supports shared subscriptions. See how the broker routes a PUBLISH to matching subscribers in the TBMQ architecture guide, and the topics & subscriptions reference for topic and wildcard rules.
Frequently asked questions
What is the difference between publish/subscribe and request/response?
In request/response (like HTTP) a client asks a specific server and waits for that server’s answer. In publish/subscribe, a publisher sends to a topic and the broker delivers to whoever subscribed — the publisher never addresses a receiver and does not wait. Pub/sub decouples senders from receivers in space, time, and synchronization.
Does the publisher know who receives its messages?
No. A publisher sends to a topic and is done; it has no knowledge of how many subscribers exist, who they are, or whether any are connected. The broker handles matching and delivery.
Can one client both publish and subscribe?
Yes. Most real clients do both — a device might publish its telemetry and subscribe to command topics on the same connection.
Is MQTT publish/subscribe the same as a message queue?
Not by default. A normal MQTT subscription is a broadcast: every subscriber to a topic gets every message. To get queue-like load balancing where each message goes to only one of several consumers, you use shared subscriptions.
What is a topic in publish/subscribe?
A topic is the named channel a message is published to and subscribers subscribe to. Topics are hierarchical, and subscriptions can use wildcards to match many topics at once.
Run it yourself
TBMQ is a free, open-source MQTT broker built to scale. Spin it up in minutes or try the live demo — no install required.