MQTT · Study deck

MQTT Architecture

MQTT routes named messages through a broker; topic contracts, stored state, and application feedback make the architecture reviewable.

Broker Bex is your guide for this deck.

topicswildcards
Mqtt Architecture cover: Broker Bex routing publish-subscribe message tokens through a broker hub, topic slots, and subscribers.
iotclass.org

After studying this chapter

Learning objectives

Review MQTT through the message route, the broker state, and the evidence beyond delivery.

  • Explain how the broker matches topics to subscriber filters.Publishers send concrete names; subscribers register the exact or wildcard routes they need.
  • Separate client roles from the state the broker stores.Sessions, retained values, and last-will configuration answer different connection and delivery questions.
  • Record identities, permissions, and evidence for each flow.A reachable broker still needs rules deciding who may publish and subscribe.
  • Distinguish delivery acknowledgements from completed application actions.A command path needs state feedback, correlation, and timeouts to establish what happened.

I start with one greenhouse warning and three screens. I check their filters and connection histories before deciding what each should receive.

iotclass.org

Major section

One warning reaches different listeners

One greenhouse warning must reach listeners with different connection histories.

  • The sensor publishes once instead of addressing each dashboard.The broker owns the fan-out to clients whose stored interests match the topic.
  • Subscribers register filters that describe their interests.The broker compares those filters with each published topic before forwarding the message.
  • Offline and late-arriving listeners need different stored-state decisions.Session policy covers reconnect behavior, while retained state can supply a later subscriber.
  • Reconnect and restart tests expose actual delivery behavior.Repeat the warning and check whether an old copy can appear current.

I disconnect one greenhouse screen and let another join late. I repeat the warning and record which copy each screen receives.

iotclass.org

Major section

Assign client and broker responsibilities

The broker decouples client addresses while taking responsibility for routing and stored state.

  • A client can publish, subscribe, or do both.A gateway may publish sensor events while subscribing to a separate command flow.
  • Publishers use concrete topics while subscribers use filters.Wildcards belong in subscription filters, not in published topic names.
  • Broker policy governs permissions and stored state.Identity, ACLs, and session decisions determine what is allowed and what survives disconnection.
  • Applications own payload meaning and action evidence.MQTT delivery alone does not establish that a device carried out a command.

I put the greenhouse broker in the middle of the sketch. I mark routing inside it and the check for current warning meaning at the screens.

iotclass.org

Activity 1 · Draw it

✎ Route the greenhouse warning

I want you to show where routing ends and application responsibility begins.

Sketch the greenhouse sensor, broker, and listening dashboards. Label the publication and subscriptions. Mark an offline listener, a late arrival, and the place where you would check whether an old warning looks current.

3 minutes · Pen and paper · Answer: Activity 1

Your answer
iotclass.org

Major section

Compare the protocol roles

These role cards compare communication contracts; begin with DDS and MQTT before checking the lower selection questions.

  • DDS writers and readers share a peer data space with no broker.Its communication contract differs from MQTT's broker-centered publication fan-out.
  • Follow MQTT publications into the topic broker.The broker matches subscriber filters and routes messages without requiring direct client relationships.
  • AMQP routes through queues; XMPP addresses federated streams.These cards highlight different routing and delivery contracts for different communication needs.
  • The lower cards turn the comparison into measurable selection questions.Power, bandwidth, latency, reliability, and security requirements guide the protocol comparison.
DDS, AMQP, MQTT, and XMPP role comparison with flow semantics and selection questions.
DDS, AMQP, MQTT, and XMPP role comparison with flow semantics and selection questions.
iotclass.org

Major section

Inspect the broker's routing and state

This broker view separates client traffic from stored policy; follow connections through matching to subscribers.

  • Follow the publishers' topics into the broker from the left.Client connections supply the sensor data, status, and command flows under review.
  • The topic index and filters decide the subscriber route.Matching determines which clients receive a publication rather than interpreting its payload meaning.
  • Sessions, retained values, and queues define what the broker remembers.Stored-state policy changes what clients receive after connection interruptions.
  • Identity and ACL policy decide whether an operation is allowed.Topic examples and permissions must agree before the route becomes a trusted command path.
MQTT broker architecture with clients, topic matching, sessions, and retained state
MQTT broker architecture with clients, topic matching, sessions, and retained state
iotclass.org

Major section

Record the command result

A command path needs application evidence as well as a broker delivery policy.

  • Separate telemetry, commands, alerts, configuration, and state feedback.Each flow needs its own clients, topic examples, and evidence requirements.
  • Record identities, allowed filters, session behavior, and broker ownership.Those decisions reveal both the trust boundary and the state retained after disconnection.
  • Command correlation and state feedback establish the result beyond delivery.Timeout and retry policy handle cases where the expected response does not arrive.
  • Reopen the review when routing or ownership changes.Broader filters, growing client counts, and safety-relevant commands can alter the architecture assumptions.

I follow a command through the broker to the device. I wait for the separate state feedback before calling the requested action complete.

iotclass.org

Major section

Follow the control-packet lifecycle

These control methods expose the broker lifecycle; read from connection setup through publication to clean teardown.

  • CONNECT and CONNACK establish the connection context first.The broker lifecycle begins with identity and session policy.
  • Follow SUBSCRIBE and SUBACK to the routing filters.The client installs its interests before receiving matching publications.
  • PUBLISH carries the concrete topic and payload.Higher QoS acknowledgement exchanges advance protocol delivery state rather than proving physical action.
  • Finish with UNSUBSCRIBE and DISCONNECT.The first removes routing interests, while the second closes the connection cleanly.
MQTT connection, subscription, publication, acknowledgement, and disconnect methods
MQTT connection, subscription, publication, acknowledgement, and disconnect methods
iotclass.org

Major section

Separate session, retained, and last-will state

Different kinds of broker state answer different questions after a connection changes.

  • Session policy governs subscriptions and queued messages after reconnect.The architecture record must name clean-start, persistence, expiry, and replay expectations.
  • A retained value supplies the latest retained snapshot.A new subscriber can receive that topic's stored value without waiting for another publication.
  • Retaining a one-time command risks repeating an old action.A reconnecting device may treat a stored request as work to perform again.
  • A last-will notice signals an unexpected disconnect.The application still needs investigation and feedback to establish what happened to the device.

I let a greenhouse screen join after the warning. I check its retained snapshot for freshness instead of assuming the arrival time proves a new event.

iotclass.org

Major section

Test topics against filters

This matching matrix tests concrete topics against filters; compare exact, plus, hash, and non-matching cases.

  • The matrix begins from one concrete published topic.Its fixed levels are compared with every stored subscription filter.
  • An exact filter requires matching text at every level.Different literal names or extra levels explain why an apparent route does not match.
  • The + wildcard matches exactly one topic level.A final # covers the remaining subtree and must end the filter.
  • The non-matching cases decide whether the route is safe to accept.Wrong levels, different names, and invalid wildcard placement change the delivery result.
MQTT deterministic topic-filter matching matrix showing one concrete published topic, exact and wildcard filters, match and non-match reasons, invalid wildcard placement, the system-topic boundary, and broker fan-out evidence.
MQTT deterministic topic-filter matching matrix showing one concrete published topic, exact and wildcard filters, match and non-match reasons, invalid wildcard placement, the system-topic boundary, and broker fan-out evidence.
iotclass.org

Activity 2 · Predict

✎ Predict the factory routing

I want you to check each topic level before drawing the delivery arrows.

Write factory/line-a/pump-17/temperature and factory/line-a/pump-17/command/start. Predict whether each matches factory/+/+/temperature. Explain how changing the topic changes delivery, then name separate evidence that the pump acted.

3 minutes · Pen and paper · Answer: Activity 2

Your answer
iotclass.org

Major section

Design topic levels from consumer needs

Design topic levels backward from the consumers that need selective subscriptions.

  • Put stable groups before the asset and final metric.Groups such as factory and line_a keep subscription boundaries understandable.
  • Separate command requests from reported state.ACLs can then distinguish who writes commands from who reads the resulting state.
  • Choose the narrowest filter that covers each consumer's job.A maintenance screen, dashboard, and controller can require different portions of the tree.
  • Keep real topic and ACL examples beside the naming rules.Reviewers can test which additional traffic a broader subscription would receive.

I list the factory dashboard and maintenance tool before naming topics. I test their different filters against real examples and keep commands separate from state.

iotclass.org

Major section

Keep reconnect work selective

Precise wildcard filters can reduce reconnect work while preserving routing boundaries.

  • Many exact subscriptions add state and reconnect work.The chapter compares reinstalling 50 exact filters with 3-5 precise wildcard filters.
  • A few well-shaped wildcard filters can remain selective.Stable level positions let each client cover its required scope without unrelated traffic.
  • A catch-all # can complicate isolation.It reduces subscription count but pushes unwanted traffic and security decisions toward application code.
  • Subscribe explicitly to required broker system namespaces.A broad application filter should not be assumed to include reserved prefixes such as $SYS/.

I compare a long exact-filter list with a few precise wildcard routes. I keep the factory boundaries visible rather than replacing the plan with a catch-all.

iotclass.org

Deck summary

Key takeaways

A reviewable MQTT architecture separates routes, permissions, stored state, and application outcomes.

  • Publish concrete names and test filters against real examples.The topic hierarchy becomes useful only when the intended subscribers actually match its topics.
  • Assign broker responsibility for routing and stored-state policy.Sessions, retained messages, and last-will behavior need explicit architecture decisions.
  • Align topic permissions with client roles and command-state boundaries.Network reach and encryption do not replace authorization for publishing and subscribing.
  • Application feedback establishes outcomes beyond protocol acknowledgements.Important commands still need evidence that the device processed the requested action.

I finish by reconnecting the greenhouse listeners and reviewing their warnings. I keep delivery evidence separate from the application check that each warning is current.

iotclass.org

Retrieval practice

Recall check 1 of 6

Broker Bex says: answer from memory, then check your reasoning.

Q1What is the main architectural role of an MQTT broker?

AReceive published messages and forward them to clients whose topic filters match.
BForce every publisher to open one direct connection to each subscriber.
CDecode every payload and decide application meaning from the message body.
DReplace TLS, authentication, and authorization with topic names alone.
Show answer

Answer: A The broker is the routing and coordination point between publishers and subscribers.

iotclass.org

Retrieval practice

Recall check 2 of 6

Broker Bex says: answer from memory, then check your reasoning.

Q2A team says, "The device received the command because the publisher used MQTT QoS 1." What should the architecture record add?

AA separate application-level state feedback path that proves the device processed the command.
BA rule that command topics must include the password so the subscriber can trust the message.
CA wildcard subscription to every command topic so operators can see all traffic.
DA retained command message so every reconnecting device repeats the latest command.
Show answer

Answer: A MQTT QoS helps with protocol delivery, but the application still needs evidence that the device acted correctly.

iotclass.org

Retrieval practice

Recall check 3 of 6

Broker Bex says: answer from memory, then check your reasoning.

Q3A subscriber uses the filter factory/+/+/temperature. Which published topic should match?

Afactory/line-a/pump-17/temperature
Bfactory/line-a/pump-17/motor/temperature
Cfactory/line-a/temperature
Dsite/factory/line-a/pump-17/temperature
Show answer

Answer: A The two plus wildcards each match exactly one level: line-a and pump-17.

iotclass.org

Retrieval practice

Recall check 4 of 6

Broker Bex says: answer from memory, then check your reasoning.

Q4Which statement best describes MQTT topics and topic filters?

AA publisher sends to an exact topic name
BPublishers put + and # in topic names so the broker can fan messages out.
CMQTT topic matching is case-insensitive, so Factory and factory are the same route.
DThe broker must parse the payload before it can decide which subscribers get the message.
Show answer

Answer: A A topic plan is a routing contract: publishers use exact names; subscribers express interests through exact or wildcard filters.

iotclass.org

Retrieval practice

Recall check 5 of 6

Broker Bex says: answer from memory, then check your reasoning.

Q5A factory publishes factory/line_a/machine_012/pressure, factory/line_b/machine_004/pressure, and many temperature topics. Which filter is the best fit for a safety service that only needs pressure readings across all lines and machines?

Afactory/+/+/pressure
Bfactory/#
Cfactory/+/pressure
Dfactory/*/*/pressure
Show answer

Answer: A Use + when a fixed number of levels vary and keep the level you care about explicit.

iotclass.org

Retrieval practice

Recall check 6 of 6

Broker Bex says: answer from memory, then check your reasoning.

Q6Why can wildcard topic design improve reconnect behavior without using a catch-all # filter?

AA few precise wildcard filters can replace many exact subscriptions while still excluding unrelated topics.
BWildcard filters make the broker ignore access-control rules.
CThe # filter is always best because it receives every message with one subscription.
DMQTT brokers route by payload fields, so topic filters only affect display labels.
Show answer

Answer: A Wildcard design is useful when it reduces subscription count while preserving routing precision and authorization boundaries.

iotclass.org

Print reference

Answers 1 of 2

Answer key.

  1. A · The broker is the routing and coordination point between publishers and subscribers.
  2. A · MQTT QoS helps with protocol delivery, but the application still needs evidence that the device acted correctly.
  3. A · The two plus wildcards each match exactly one level: line-a and pump-17.
  4. A · A topic plan is a routing contract: publishers use exact names; subscribers express interests through exact or wildcard filters.
iotclass.org

Print reference

Answers 2 of 2

Answer key.

  1. A · Use + when a fixed number of levels vary and keep the level you care about explicit.
  2. A · Wildcard design is useful when it reduces subscription count while preserving routing precision and authorization boundaries.
iotclass.org

Print reference

Activity 1 answer

Model answer.

Draw it: The sensor publishes to the broker, which matches stored filters and fans out to interested dashboards. Session policy governs offline delivery; retained state can supply a late subscriber. Application freshness checks must distinguish an old warning from current evidence.

iotclass.org

Print reference

Activity 2 answer

Model answer.

Predict: The temperature topic matches: the two + levels replace line-a and pump-17, and temperature matches literally. The command topic does not match the final temperature level. Application state feedback must establish pump action beyond MQTT delivery acknowledgements.

iotclass.org