MQTT

Route map for the MQTT module, connecting publish-subscribe architecture, topics, QoS, sessions, security, implementation, and production review.

Keywords

MQTT, IoT messaging, publish-subscribe, MQTT topics, MQTT QoS, MQTT broker

Your guide: Broker Bex

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

MQTT Module Guide

MQTT is the application protocol many IoT systems use when devices publish telemetry, receive commands, and reconnect across unreliable links. This module groups the MQTT chapters into a focused book so the protocol can be built, searched, and reviewed as its own route.

Use this book when you need to reason about MQTT as a system design choice, not just as a client library. The chapters move from broker and topic architecture through QoS, sessions, security, implementation patterns, labs, and production deployment evidence.

Start With One Message

Imagine one sensor reading leaving a device: it needs a topic name, a broker route, a delivery promise, a session rule, and proof that the right subscriber received it. This module follows that message from first publication to production operation so MQTT feels like a system you can inspect, not a library call you hope works.

Recommended Route

1. Start with MQTT Architecture to understand clients, brokers, routing, sessions, retained messages, and last will behavior.
2. Use MQTT Topic Design and Wildcards before building a topic tree or access-control boundary.
3. Read MQTT Publish-Subscribe Basics if the publisher, subscriber, and broker roles are still new.
4. Review MQTT Security Fundamentals, MQTT Advanced Fundamentals, MQTT Quality of Service Levels, and MQTT Session Management before production design.
5. Move into MQTT Implementation Basics, MQTT Python Patterns, and MQTT Implementation Hands-On Labs when you are ready to build and test.
6. Finish with MQTT Production Deployment to review clustering, TLS, ACLs, session storage, monitoring, and rollout evidence.

Design Questions

• What does each topic represent, and who is allowed to publish or subscribe to it?
• Which messages can tolerate loss, duplicates, delays, or replay?
• Does the system need retained messages, persistent sessions, or last will notifications?
• Where is security enforced: TLS, client identity, topic ACLs, broker policy, or application confirmation?
• What production evidence proves the broker, clients, and monitoring behave as expected?

Related Protocols

MQTT is strongest when many devices or services need decoupled publish-subscribe messaging. Compare it with CoAP for constrained resource-oriented systems, REST/HTTP for request-response APIs, and AMQP for durable enterprise queue routing.