MQTT · Study deck

MQTT Production Operations

Picture a building service that accepts thousands of sensor messages during a calm test.

Broker Bex is your guide for this deck.

reviewproduction

Broker Bex, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

Build a review record from failover, security, capacity, and message needs.

Test broker state after failover.Check subscriptions, queued messages, and retained values.
Test transport, identity, and topic rules.Keep each security control as a separate check.
Measure the service bottlenecks.Use the chosen workload and record observed delay.
Choose QoS from message consequences.Loss and duplicates guide the service level choice.

Major section

In 60 Seconds

On release day, one service copy stops, stored work grows, and devices reconnect together.

The test message succeeded, but the operating promise was never proved.
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) carries named messages through a broker.

Major section

In 60 Seconds (continued)

A broker is the service that receives and routes them.

Latency means time from sending to a useful result.
Quality of service means rules for different delivery handling.
Transport layer security is protection for data moving across a network.
Transport Layer Security (TLS) protects a connected path.

Major section

In 60 Seconds (continued)

This rehearsal cannot prove every future load or outage.

Production MQTT deployments need capacity and recovery plans sized to their workload.
A broker cluster is one option; its load balancing, session recovery, retained state, and QoS queues depend on the chosen broker and its configuration.
TLS, client authentication, and topic-level authorization should be tested as separate controls.

Major section

MQTT Broker Clustering Architecture · Checkpoint: Cluster Sizing

Trace publisher traffic through the load balancer to broker state.

A load balancer moves client connections.
The figure shows three broker nodes.
The test must verify shared subscriptions and queued state.

MQTT broker cluster with a load balancer, three broker nodes, shared session state and message queues, publishers, subscribers, and failover benefits. — MQTT broker cluster with load balancer, three broker nodes, shared session state, publishers, subscribers, and failover benefits

Major section

Security Configuration

This enables TLS with mutual authentication.

Production example: The sensor_device login can publish only under sensors/device_123/# and read commands/device_123; the example grants no access to other devices' branches.
Application-layer encryption only: Misses metadata (topic names visible), doesn't protect credentials.
Cloud providers: AWS IoT Core supports X.509 or custom authentication; Azure IoT Hub supports X.509 or SAS tokens; HiveMQ Cloud defaults to username/password and offers other methods by plan.

Major section

Common Pitfalls

The Mistake: Developers set QoS 2 (exactly-once delivery) for all messages, assuming higher QoS always means better reliability without considering the costs.

Packet-count impact: A completed QoS 2 exchange uses four MQTT control packets versus one for QoS 0 and two for QoS 1.
Actual latency and battery impact need measurement on the target hardware and network.

MQTT QoS selection decision tree matching delivery guarantees to message criticality

Major section

Common Pitfalls (continued)

For 10,000 sensors publishing once per second, that is 40,000 versus 10,000 control packets per second on the publisher-to-broker legs, before subscriber fan-out.

The decision starts with what happens if one publication is lost or repeated, not with the assumption that a larger QoS number is always safer.
If delivery matters but the consumer can make duplicate processing safe, QoS 1 supplies retransmission with a simpler exchange.
This ordered choice connects the pitfall's broker and battery cost to a per-message requirement rather than a universal setting.

Major section

Checkpoint: Secure and Efficient Operations · Protocol Bridging

A gateway translates local sensor traffic for the cloud route.

CoAP sensors communicate with the gateway.
The gateway normalizes events before forwarding.
MQTT carries cloud traffic over TCP.

Major section

Packet count at scale

QoS changes publisher-leg packet work; this is not an energy measurement.

Ten thousand publishes each second use ten thousand QoS-zero publisher-leg packets.
A completed QoS-two exchange uses four packets per publish.
Forty thousand packets per second excludes subscriber forwarding.

Major section

Visual Reference Gallery

Compare exact and wildcard filters with concrete topics.

Exact filters match the full topic name.
Plus matches one topic level.
Hash covers remaining descendants.

MQTT exact, single-level, and multi-level subscription filters matched against concrete published topics. — MQTT deterministic broker matching with exact, single-level and multi-level subscription filters

Major section

Worked Example: Sizing an MQTT Broker Cluster for a Smart Building · Checkpoint: Release Evidence

The workload assumptions produce a planning estimate, not capacity evidence.

Forty floors include sensors and actuators.
Sensor readings create three subscriber deliveries.
Load-test the selected broker and failover path.

40 floors × (80 sensors + 20 actuators) = 4,000 devices.
Sensors: 3,200/30 ≈ 106.7 messages/s. Commands: 800/60 ≈ 13.3/s.
Sensor fan-out: 3 × 106.7 = 320/s.
Unrounded total ≈ 440/s; rounded worksheet terms 107 + 13 + 321 = 441/s. Load-test the chosen broker.

Major section

Deep-Dive Note: Production Observability Boundaries

The $SYS tree is the broker's read-only metrics namespace, but it has a wildcard trap: ordinary # and + subscriptions do not match topic names beginning with $.

A production MQTT review should prove that failures are visible before users report them.
Flow control with Receive Maximum caps unacknowledged QoS 1/2 messages so a slow consumer cannot create unbounded broker memory pressure.
Bridging is a security and namespace decision as much as a scaling tool.

Major section

Reference: MQTT Quick Reference Card

Message Queuing Telemetry Transport (MQTT) means a lightweight way for devices to exchange messages.

A protocol means shared rules for that exchange.
A broker means the service that passes messages from senders to receivers.
A payload means the useful data inside one message.
Transmission Control Protocol (TCP) means a stream that checks order and delivery.

Major section

Reference: MQTT Quick Reference Card (continued)

Transport layer security means protection for that stream; it is called TLS.

A WebSocket means a lasting two-way link between a browser and a service.
Quality of service means the delivery promise chosen for a message; it is called QoS.
A broad subscription such as # or +/status does not receive $SYS/. Messages; subscribe with a filter that also starts with $, such as $SYS/#, when broker telemetry is the intended target.

Deck summary

Key takeaways

On release day, one service copy stops, stored work grows, and devices reconnect together.

A broker is the service that receives and routes them.
This rehearsal cannot prove every future load or outage.
The load balancer distributes connections, but correct failover also depends on replicated subscriptions, queued QoS traffic, and retained state; adding nodes alone does not supply those guarantees.
This enables TLS with mutual authentication.

Retrieval practice

Recall check 1 of 5

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

Q1A load balancer moves clients to healthy MQTT broker nodes. What must the failover review still prove?

ACheck only broker startup, not subscriptions or queued messages after move.

BCheck TLS alone because an encrypted connection preserves broker state during a failover.

CCheck publisher reconnect alone without subscriber or retained-state tests.

DVerify subscriptions, queues, and retained state survive node failover.

Show answer

Answer: D Moving connections alone does not preserve broker state.

Q2Set up bounded automatic reconnect delays before starting the Paho network loop; the disconnect callback should only record the reason.

Aclient.reconnect_delay_set(1, 60)

Btime.sleep(1)

Cclient.reconnect()

Dclient.connect()

Show answer

Answer: A

Retrieval practice

Recall check 2 of 5

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

Q3A production IoT system connects 5,000 devices using MQTT on port 1883 with username/password authentication. A security audit flags this as a critical risk. Which combination of changes BEST resolves the identified vulnerabilities?

AUse TLS, stronger authentication, and device-scoped topic ACLs.

BKeep port 1883 with VPN and passwords, omitting topic ACL review.

CUse TLS on 8883 alone because encryption also limits which topics a client may publish.

DEncrypt payloads while keeping 1883 and broad broker permissions.

Show answer

Answer: A Port 8883 with TLS encrypts the transport layer (preventing credential and payload sniffing), client certificates provide mutual TLS authentication (stronger than username/password), and topic ACLs enforce least-privilege access control.

Retrieval practice

Recall check 3 of 5

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

Q4A smart building deploys 4,000 IoT devices that each publish replaceable sensor readings every 30 seconds. The team uses QoS 2 for all messages to 'maximise reliability'. Broker CPU reaches 90% at peak. Which analysis BEST explains the root cause and recommends the correct fix?

AThe broker hardware is underpowered; upgrade CPU cores to handle QoS 2 overhead

BQoS 2 is appropriate for sensor data; the real problem is too many subscribers causing fan-out

CDowngrade periodic sensor readings to QoS 0 and reserve QoS 1 for critical safety alerts

DSwitch to a clustered broker to distribute the QoS 2 processing across multiple nodes

Show answer

Answer: C QoS 0 has no acknowledgment packet for replaceable periodic data; QoS 2 uses four control packets on a completed MQTT leg versus one for QoS 0.

Retrieval practice

Recall check 4 of 5

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

Q5What edge fleet owns unique MQTT client identities, credentials, allowed topics and bounded publish rates?

AHA Broker Cluster and Session State

BBackend Processing and Observability

CAuthenticated Device Fleet

Reveal answer

Identity → fleet; routing and state → broker; processing and monitoring → backend.

Question five: Device identity → ?; topic routing and queued state → ?; application processing and monitoring → ?
Targets: fleet, broker, and backend.

Show answer

Answer: C The authenticated device fleet owns unique client identity, TLS credentials, allowed topics, reconnect behavior, and bounded publish rates at the edge.

Retrieval practice

Recall check 5 of 5

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

Q6Per this MQTT cheat sheet, which QoS level uses a 4-way handshake to guarantee exactly-once delivery?

AQoS 2

BQoS 0

CQoS 1

DQoS 3

Show answer

Answer: A The cheat sheet lists QoS 0 as at-most-once (fire and forget), QoS 1 as at-least-once (with PUBACK), and QoS 2 as exactly-once (4-way handshake).

Print reference

Answers 1 of 2

Answer key.

D · Moving connections alone does not preserve broker state.
A · client.reconnect_delay_set(1, 60)
A · Port 8883 with TLS encrypts the transport layer (preventing credential and payload sniffing), client certificates provide mutual TLS authentication (stronger than username/password), and topic ACLs enforce least-privilege access control.
C · QoS 0 has no acknowledgment packet for replaceable periodic data; QoS 2 uses four control packets on a completed MQTT leg versus one for QoS 0.

Test broker state after failover; set reconnect delays before starting the loop. Require device identity and topic rules. Match QoS to message needs. Trace incidents across fleet, broker, and backend logs. The building worksheet rounds to 441 events per second; unrounded inputs give about 440.

Print reference

Answers 2 of 2

Answer key.

C · The authenticated device fleet owns unique client identity, TLS credentials, allowed topics, reconnect behavior, and bounded publish rates at the edge.
A · The cheat sheet lists QoS 0 as at-most-once (fire and forget), QoS 1 as at-least-once (with PUBACK), and QoS 2 as exactly-once (4-way handshake).

Quality of service two is the four-step MQTT exchange for one protocol leg, not proof that a physical command occurred. Release evidence should cover capacity, node recovery, denied topic actions, and application state.