Picture a temperature sensor with one reading to share and three dashboards that may or may not be online. MQTT solves that problem by putting a broker in the middle: the device publishes once, subscribers express what they care about, and the broker owns the routing and state evidence. Start with that path before choosing topics, sessions, retained messages, or last-will behavior.
MQTT is a publish-subscribe protocol built around a broker. A publisher sends a message to a topic. A subscriber registers a topic filter. The broker compares the published topic with the filters and forwards matching messages.
The key architectural idea is decoupling. Publishers do not need subscriber addresses, and subscribers do not need publisher addresses. Both sides keep one application relationship with the broker instead of a growing set of direct relationships with each other.
Broker Bex
“A message with no subscriber is a tree falling in an empty forest — design the topic before the payload.”
In this chapter, Bex checks the architecture record for three things: who may publish, what the broker is asked to remember, and what still needs its own proof beyond delivery.
graph LR
P1["Publisher: sensor"] -->|publish topic| B["Broker"]
P2["Publisher: gateway"] -->|publish topic| B
B -->|match filter| S1["Subscriber: dashboard"]
B -->|match filter| S2["Subscriber: logger"]
If you only need the intuition, this layer is enough: MQTT architecture is a hub for application messages. The broker owns routing, session state, retained messages, and delivery negotiation; devices own the meaning of the payloads they publish and consume.
A client can publish, subscribe, or do both. The role is per flow, not per device: a gateway may publish sensor events and subscribe to command topics.
The topic tree is the routing contract. It should express stable ownership, location, asset, event type, or command boundary.
The broker may hold subscriptions, session state, retained messages, queued messages for persistent sessions, and last-will configuration.
building/a/floor/2/room/204/temperature; dashboards subscribe to the parts of the tree they need.If this gives you the broker model, you can stop here. Continue to Practitioner when you need to design and review a brokered MQTT deployment.
A reviewable MQTT design does not start with sample code. It starts with a short architecture record that says which clients connect, what they publish, what they subscribe to, what the broker stores, and what evidence proves the system is operating correctly.
Devices publish readings under stable measurement topics. Dashboards and analytics subscribe with filters that match their scope.
Operators publish command requests to device-specific command topics. Devices publish state feedback to separate state topics.
Reopen the architecture decision when topic filters broaden, client counts grow, broker ownership changes, or command confirmation becomes safety relevant.
Bex’s Topic Board
At the protocol level, MQTT clients exchange control packets with the broker. The common architecture path is CONNECT, CONNACK, SUBSCRIBE, SUBACK, PUBLISH, acknowledgement packets for higher QoS levels, and DISCONNECT. The details matter because the broker's state machine is what turns topic strings into reliable operating behavior.
The broker compares each published topic name with stored subscription filters. The single-level wildcard + matches exactly one topic level. The multi-level wildcard # matches the remaining levels and must appear at the end of the filter. Published topic names are concrete names; wildcard characters belong in subscription filters.
The broker may remember subscriptions and queued messages for a client across reconnects, depending on the session policy and broker configuration.
A retained message gives new subscribers the latest retained value for a topic. It is useful for state snapshots and risky for one-time commands.
A last-will message lets the broker publish a preconfigured status if a client disconnects unexpectedly. Treat it as a signal to investigate, not a complete fault diagnosis.
Bex’s Topic Board
+ matches exactly one level; a multi-level # takes the rest and must end the filter.publish topic: factory/line-a/pump-17/temperature
subscriber filter: factory/+/+/temperature
match result: yes, because + matches line-a and pump-17
publish topic: factory/line-a/pump-17/command/start
subscriber filter: factory/+/+/temperature
match result: no, because the final level differsReliability boundary: MQTT QoS describes message exchange between an MQTT client and broker, and between broker and subscriber. It does not prove that a machine moved, a valve opened, or a database committed the business action. Critical actions need application-level confirmation.
MQTT architecture is broker centered. Clients publish concrete topic names, subscribers register topic filters, and the broker routes matching messages while managing session-related state. The strongest designs treat topics, sessions, retained messages, last will, identity, and command confirmation as architecture decisions rather than code details.
Design MQTT around broker responsibilities and review evidence: who connects, which topics route messages, what state the broker stores, and how the application proves important actions actually happened.
Use this next to practice the client-side publishing and subscribing pattern that sits on top of the broker architecture.
Deepen the topic hierarchy and wildcard rules that make broker routing predictable.
Connect architecture decisions to QoS tradeoffs, acknowledgements, duplicates, and delivery boundaries.
Review identity, ACLs, transport protection, and broker hardening after the routing model is clear.