MQTT brokers coordinate publish and subscribe traffic between connected clients. Their value is not simply moving messages; it is creating a controlled boundary where client identity, topic authority, session behaviour, delivery options, and operational evidence can be managed. A broker architecture should make it clear who may publish, who may subscribe, what a message means after a reconnect, and how the team responds when the broker or a client is unavailable.
What an MQTT broker does
A client publishes to a topic and other clients subscribe to topic filters. The broker authenticates clients, applies authorization, routes messages, manages sessions, and may apply retention or delivery semantics according to configuration. It does not automatically define asset identity, quality, command safety, or business ownership. The MQTT broker guide for connected systems helps teams compare the broker with direct ingestion. Keep protocol responsibility separate from application meaning. Broker rollout context continues in MQTT production changes and MQTT first-build decisions.
| Broker concern | Decision | Evidence |
|---|---|---|
| Client identity | How is each client recognised and revoked? | Certificate or credential lifecycle |
| Topic authority | Who may publish or subscribe where? | ACL matrix and denied tests |
| Delivery | What happens to delayed or duplicate messages? | QoS, expiry, retry exercise |
| Session | What survives a disconnect? | Reconnect and subscription test |
| Operations | How is capacity and failure seen? | Metrics, logs, traces, runbook |
Design topics as an authority boundary
Topic names should reflect stable ownership and routing needs rather than every current screen. Separate telemetry, state, commands, and command results. Keep tenant, site, and asset scope explicit where the authorization model depends on them. Avoid putting mutable customer names in the only route to a device. Define payload identity, observed time, quality, schema, and producer version inside the message contract. A topic hierarchy is not a security policy until the broker enforces it with tested permissions.
Set MQTT delivery guarantees
MQTT quality-of-service levels express delivery intent, not business success. A higher delivery guarantee may increase state, bandwidth, and recovery work. If a duplicate command could cause harm, the consumer needs an idempotency key, expiry rule, or a different command workflow. MQTT Version 5.0 documents sessions, message expiry, reason codes, and other controls; choose them from the consequence of delay, loss, or duplication. Test the whole consumer path, not just broker acknowledgements.
- Keep client identifiers unique and lifecycle-managed.
- Use narrow topic permissions for each device and service role.
- Record event and receipt time separately when messages can be delayed.
- Define whether retained state is authoritative, cached, or merely a last-known value.
- Make reconnect, backlog, and duplicate handling visible to operators.
Secure clients and broker boundaries
Use encrypted transport, unique credentials or certificates, least-privilege ACLs, rate and payload limits, and a revocation path. NISTIR 8259A frames capabilities such as device identification and data protection; NIST SP 800-213A helps turn requirements into testable controls. Segment broker access from administrative access. A client that may publish telemetry should not gain the ability to subscribe to every tenant or publish a command topic.
| Control | Broker implementation question | Pass evidence |
|---|---|---|
| Authentication | Can one client be revoked independently? | Revoked client rejected |
| Authorization | Are publish and subscribe scopes distinct? | Allowed and denied matrix |
| Capacity | What limits protect broker and consumers? | Rate and payload test |
| Sessions | What state survives reconnect? | Clean and persistent session test |
| Administration | Who may change ACLs or retention? | Role and change audit |
Operate the broker as production infrastructure
Monitor connected clients, authentication failures, publish and subscribe rates, payload rejects, retained state, session counts, queue depth, delivery latency, consumer lag, and broker resource pressure. Correlate a user-visible stale state with client status and broker logs. OpenTelemetry documentation can support a common signal model, but the broker runbook should say which signal changes the operator’s next action. Review topic growth and abandoned clients before they become capacity surprises.
Exercise broker recovery
Test a broker restart, network partition, credential rotation, subscriber outage, duplicate delivery, full queue, and a malformed message. Record what the client sees, what the broker retains, how long recovery takes, and whether a downstream action repeats. Decide whether a retained message is still valid after the underlying asset has changed state. NIST SP 800-82 Rev. 3 keeps availability and safe failure in view when a broker supports operational technology.
Plan capacity and tenancy
Broker capacity is shaped by connected clients, session state, topic subscriptions, retained messages, payload size, publish rate, consumer lag, and recovery behaviour. Estimate the normal and burst cases, including a site reconnecting after an outage. Set limits before the broker is busy: maximum payload, publish rate, session count, queued messages, and retained state. A limit should produce a visible, actionable result rather than an unexplained disconnect. Review capacity by tenant or site when one customer can affect another.
Topic design and tenancy need to agree. A hierarchy that makes subscriptions convenient can accidentally widen access if ACLs rely on a wildcard or a mutable name. Define the permitted publish and subscribe scopes for each device, service, operator, and support role. Test a valid cross-site operation and an invalid cross-tenant attempt. Keep administrative topics separate from application topics and protect broker management interfaces with an independent authority path.
Retained messages and persistent sessions should have an invalidation story. A retained state may outlive the asset, firmware, tenant, or measurement that produced it. A persistent session may replay messages after a consumer has changed its interpretation. Record expiry, schema, producer version, and current-state rules so a reconnect cannot make old information appear newly observed. The safest retained value is one whose age and source state are visible to every consumer.
Broker upgrades deserve a compatibility exercise. Test client libraries, authentication, ACLs, subscriptions, QoS behaviour, retained state, session recovery, and monitoring against the candidate version. Keep a rollback plan that does not require every device to reconnect at once. NIST SP 800-213A is useful when reviewing the device-side requirements that a broker change may expose, especially around identity and secure communication.
Finally, assign a review owner for abandoned identities and topics. Devices are replaced, customers leave, and prototypes become forgotten subscriptions. Stale credentials and unbounded topic growth increase both risk and operating cost. A periodic inventory should compare broker state with the provisioning and service records, close unused access, and preserve only the history that has a stated purpose.
| Capacity or tenancy check | Healthy result | Warning sign |
|---|---|---|
| Reconnect burst | Backlog drains within a safe window | Recovery overloads consumers |
| Wildcard ACL | Scope is limited to intended tenant or site | One client can read unrelated topics |
| Retained state | Age, producer, and expiry are visible | Old state appears current |
| Session recovery | Replay is understood and idempotent | Reconnect repeats side effects |
| Topic inventory | Unused paths and clients are reviewed | Permissions grow without owner |
Keep broker configuration close to the application and provisioning contracts, but do not let every service edit it. Review ACLs, retained state, session policy, and topic ownership together because a change in one can alter the effective authority of another. When a client is retired, remove its credential, subscriptions, retained state, and operational record according to the documented policy. This closes the lifecycle rather than leaving an apparently harmless but still trusted identity behind.
A broker review should include consumer behaviour, not just broker health. Ask whether consumers acknowledge, deduplicate, expire, and reconcile messages safely. A broker can be green while a consumer is silently behind or repeatedly applying an old command. Measure the business-facing result alongside connection and queue metrics, and make the consumer owner part of the review.
Document the broker’s limits in the same place as its topic and identity rules. Operators need to know what happens when a client exceeds rate, payload, session, or queue limits, and developers need to know whether a rejected publish can be retried safely. Use representative load and outage exercises to verify that the limit protects the service without creating an invisible data gap. A clear limit is easier to support than a failure caused by an undocumented capacity assumption.
Keep a consumer-facing definition of current state. If a subscriber receives a retained value, a replayed session message, or a delayed observation, it should know the age, source, and quality before displaying or acting on it. This is especially important when MQTT brokers bridge sites and services with different clocks or availability. The broker can route the message, but the consumer must decide whether the message is still fit for its purpose.
Keep the broker decision record current when a new consumer, site, tenant, or device class is added. A topic that was safe for one purpose may become too broad when another service subscribes, and a session policy that worked for telemetry may be unsafe for commands. Review the authority and recovery assumptions with the new consumer owner before expanding access.
Broker operating takeaways
- An MQTT broker is an authority and recovery boundary, not only a message router.
- Design topics and payloads together so routing does not replace meaning.
- Select QoS, session, expiry, and retention from the consequence of failure.
- Enforce unique identity and narrow publish and subscribe permissions.
- Monitor clients, queues, lag, rejects, and reconnect behaviour with a clear runbook.
Broker architecture questions
Which MQTT quality of service should we use?
Choose it per message class and consequence. A telemetry stream may tolerate loss or duplicates differently from a command. The consumer must still be designed for expiry, retries, and idempotency; broker acknowledgement is not physical completion.
When should a team use retained messages?
Use retained state when a new subscriber needs a current last-known view and the team can define its freshness and invalidation rules. Do not treat an old retained value as proof that the asset is currently healthy.
Conclusion: a traceable broker
MQTT broker architecture becomes dependable when client identity, topic authority, delivery semantics, session recovery, and operational evidence are designed as one system. Start with the workflow, test normal and degraded paths, and keep the broker’s convenience from becoming hidden authority. That is the difference between a broker that connects devices and one that can support connected operations.