2 MQTT Architecture

2.1 Start With One Sensor Message

Follow One Reading to Every Listener

Picture a greenhouse sensor with one heat warning and three screens that need it. One screen is offline, another joins late, and the third loses its link just after the warning. Sending the same reading separately to each screen creates three different failure paths.

Telemetry means readings and status sent by a remote device. A protocol is an agreed set of message and timing rules. Message Queuing Telemetry Transport (MQTT) is a protocol for passing named messages through a broker. A broker is the service that receives a published message and routes it to interested listeners.

Draw one path from the sensor to the broker and from the broker to each listener. Then disconnect a listener, repeat the warning, restart the broker, and let a new listener arrive. Record which copy each screen receives, what state is kept, and whether an old warning can look new. Treat network reach as separate from permission to read or send.

This path test does not choose every topic, delivery level, or storage rule. The deeper sections show how names, sessions, retained state, last-will notices, and security boundaries turn the simple route into a reviewable design.

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.

2.2 The Broker Separates Senders From Receivers

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.

MQTT is not a recent invention: IBM introduced it in 1999 for monitoring oil-pipeline telemetry over slow, unreliable satellite links, and the protocol was later standardized by OASIS in 2013 and published as ISO/IEC 20922. That original brief — connectivity over networks that are slow, lossy, and battery-constrained — is still why the same broker model now carries Facebook Messenger's chat delivery, AWS IoT Core and Azure IoT Hub telemetry, the EVRYTHNG M2M platform, and hobbyist projects on Adafruit IO: very different scales, the same decoupled publish-subscribe contract.

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.

2.3 Protocol Role Comparison

Inspect Figure 2.1 to compare communication contracts without treating MQTT as the universal answer.

Read Figure 2.1 by comparing DDS, which connects writers and readers through a peer data space, with MQTT, which fans publishers through a topic broker. AMQP highlights durable queue routing and XMPP highlights addressed federated streams; the lower cards keep power, bandwidth, latency, reliability, and security as measured questions.

Before assigning topic or session policy, inspect Figure 2.2 to trace two publishers through the broker to subscribers with different filters. The point is to see what becomes decoupled, how one publication can fan out, and what responsibility moves into the middle. The match-evidence band makes the routing result explicit instead of leaving the arrows to imply it.

Read Figure 2.2 from the sensor and gateway into the broker, following their concrete topic names rather than receiver addresses. Inside the boundary, authentication and authorization precede topic indexing, stored-filter matching, fan-out, and session-state handling. Then test the three filters against the evidence band: plant/7/temp matches both plant/+/temp and plant/#, so one publication reaches the dashboard and logger; building/a/air matches only building/+/air, so the alert service receives it while the plant subscribers do not. This separation is the chapter’s running architecture: client roles define flows, the topic tree defines routing, and broker policy defines what is allowed and what survives disconnection.

The Three Pieces To Name First

Beginner Examples

These examples show how topics connect devices and services. A temperature node publishes to building/a/floor/2/room/204/temperature; dashboards subscribe to the parts of the tree they need. A maintenance service subscribes to fault topics without changing device firmware. A gateway can bridge non-MQTT sensors into MQTT by publishing normalized events under agreed topics.

Overview Knowledge Check

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.

2.4 Build The MQTT Architecture Record

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.

Before filling in the architecture record, inspect Figure 2.3 to separate routing inputs from the state and policy the broker retains. That distinction determines which evidence belongs to a client and which belongs to broker operations.

Read Figure 2.3 from client connections to the topic index, then through matching and stored state to subscriber delivery. The topic name and filter decide the route; session, retained-message, and queue policy decide what the broker remembers; identity and ACL policy decide whether the operation is allowed. This ordered view turns the template below into a review of one coherent broker boundary.

Walkthrough: From Message Flow To Broker Decision

Follow the sequence from decision to evidence. First, Name the flow. Separate telemetry, command, alert, configuration, and state-feedback messages. Next, Name the clients. Record publishers, subscribers, gateways, brokers, bridges, dashboards, and backend services. Next, Name the topic tree. Define the stable topic levels and the wildcard filters subscribers are allowed to use. Next, Name the session policy. Decide clean start, persistent subscription, queued delivery, retained message, and last-will behavior per flow. Next, Name the trust boundary. Record client identity, ACLs, TLS policy, certificate or credential handling, and bridge boundaries. Finally, Name the evidence. Keep broker logs, connection counts, subscription records, publish acknowledgements, dead-letter or error handling, and application-level state feedback for commands.

Architecture Record Template

Worked Example: Building Telemetry And Command Channels

Practitioner Knowledge Check

2.5 Routing, Packets, Sessions, And State

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.

To connect the broker state machine to observable packets, inspect Figure 2.4 in lifecycle order rather than treating the methods as an unordered API list.

Read Figure 2.4 from connection setup to subscription management, publication and acknowledgement, then teardown. CONNECT establishes identity and session policy; SUBSCRIBE installs routing filters; PUBLISH carries a concrete topic and payload; acknowledgement packets advance QoS state; and DISCONNECT closes cleanly. This packet order is the evidence trail behind the broker responsibilities named above.

Topic Matching Is Deterministic

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.

Inspect Figure 2.5 to test the matching rules against concrete examples before broad filters become ACL or fan-out mistakes.

Read Figure 2.5 from the concrete published topic across each stored filter. Exact text must match level by level; + substitutes for one level; and a final # accepts the remaining descendants. The non-matches expose extra levels, different literals, and invalid wildcard placement. This deterministic comparison connects topic taxonomy to the subscribers and permissions that the architecture record must predict.

State Boundaries To Review

Implementation Sketch

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 differs

After predicting the two matches in the sketch, inspect Figure 2.6 to check the broker’s fan-out and the boundary beyond which MQTT acknowledgements provide no physical proof.

Read Figure 2.6 from each concrete factory topic to the candidate filters, checking one level at a time. The temperature publication matches the two + levels and the final literal, while the command path fails that last comparison. Then follow delivery to the application boundary: broker routing and MQTT acknowledgement can prove a protocol exchange, but device state feedback must prove that the pump acted. This completes the chapter’s route from topic design to operational evidence.

Under-The-Hood Knowledge Check

The broker path and packet anatomy in Figure 2.7 show exactly which state the architecture must route and which state belongs to delivery control.

In Figure 2.7, BROKER · Topic match fans one publication to SUBSCRIBER A and SUBSCRIBER B without coupling them to the boiler sensor. The FIXED header carries PUBLISH flags, LENGTH frames the remainder, TOPIC NAME selects routes, and PACKET ID exists for QoS 1/2 state rather than application identity.

2.6 MQTT Topic Design and Wildcards

2.6.2 MQTT Topics Are Message Addresses; Filters Choose Which Addresses A Client Receives

An MQTT topic is a case-sensitive UTF-8 name attached to a published message. Brokers do not inspect the payload to decide who receives the message; they compare the published topic with each subscriber's topic filter.

Read the diagram from the concrete topic tree downward. The publisher sends names such as home/kitchen/temp; the subscriber chooses how much of that tree it wants. home/+/temp is selective because it fixes the first and last levels while allowing one room name to vary. home/kitchen/# is broader because it accepts anything below the kitchen branch, including deeper subtopics. Those two wildcard types solve different routing problems, so a good topic plan keeps levels consistent enough that a subscriber can choose the narrowest filter that still covers its job. If a team cannot explain which level each wildcard represents, the topic tree is not yet stable enough for production ACLs or dashboards. Review filters with real sample topics before release.

Broker Bex

“A message with no subscriber is a tree falling in an empty forest — design the topic before the payload.”

Through this chapter, Bex reads the topic tree the same way every time: name first, filter second, subscriber last.

Topic Name

The publisher's exact route, such as factory/line_a/machine_012/temperature. Publish topics do not use wildcards.

Topic Filter

The subscriber's match pattern. It may be exact or use the MQTT wildcards + and #.

Topic Level

Each segment between slashes is a level. The levels in home/kitchen/thermostat/state are home, kitchen, thermostat, and state.

Rule of thumb: design topics around stable routing questions: who owns the device, where it is, which asset it represents, and what measurement or command it carries.

Good Shape

factory/line_a/machine_012/temperature
factory/line_a/machine_012/vibration
factory/line_b/machine_004/pressure

Fragile Shape

/Factory/Line A/Machine 012 Temperature
machine_012_temperature
factory/line_a/machine_012/status_and_command

2.6.5 Figure Review: Methods, Topics, and Transport

MQTT methods share one ordered connection, while topic filters decide message routing and access control decides whether that routing is permitted.

Figure 2.8 places CONNECT · PUBLISH and SUBSCRIBE · delivery around the BROKER, then contrasts site/+/temperature with site/#; the TRANSPORT + SECURITY stack shows MQTT control packets inside TLS over an ordered TCP byte stream, leaving per-topic ACLs as a separate decision.

2.7 Summary

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.

2.8 Key Takeaway

2.9 See Also