MQTT Explained: Topics, QoS, Retained Messages, and Reliable IoT Messaging

What MQTT is

MQTT (Message Queuing Telemetry Transport) is a lightweight publish/subscribe messaging protocol designed for constrained devices and unreliable networks. Clients connect to a broker, publish messages to topics, and subscribe to topics they care about — without needing direct peer connections.

Core building blocks

• Broker: Central message router (e.g., Mosquitto, EMQX, HiveMQ, cloud IoT brokers).
• Client: Device, gateway, or backend service that publishes/subscribes.
• Topic: Hierarchical string path such as site/a/device/42/telemetry/temp.
• Payload: Usually JSON, CBOR, or compact binary.

Topic design that scales

Good topic trees encode ownership and access boundaries:

• {org}/{site}/{deviceId}/telemetry/{metric}
• {org}/{site}/{deviceId}/command/{action}
• Avoid unbounded high-cardinality segments that break ACL management.
• Separate telemetry, events, commands, and config channels.

QoS levels — what they really mean

• QoS 0: At most once. Lowest overhead. Fine for high-frequency non-critical samples.
• QoS 1: At least once. Possible duplicates — design idempotent consumers.
• QoS 2: Exactly once delivery handshake. Higher overhead; use sparingly.

Most industrial IoT systems standardize on QoS 0 for dense telemetry and QoS 1 for commands/alarms.

Retained messages, Last Will, and sessions

• Retained: Broker stores last message per topic for new subscribers (great for “current state”).
• Last Will and Testament (LWT): Broker publishes a death notice if the client disconnects uncleanly.
• Persistent sessions: Help reconnecting devices resume subscriptions; manage carefully at fleet scale.

Security essentials

• MQTT over TLS (port 8883 patterns) in production
• Per-device credentials or certificates — never shared passwords
• Broker ACLs mapped to topic trees
• Rate limits and max payload sizes to protect the broker

Reliability patterns

Networks drop. Devices should buffer locally, use exponential reconnect backoff, include message IDs/timestamps, and make command handlers idempotent. Backends should tolerate duplicates from QoS 1.

MQTT vs HTTP for IoT

HTTP is request/response and heavier for frequent small messages. MQTT keeps a session and pushes efficiently both ways — ideal for telemetry + remote commands. Many systems use both: MQTT for live data, HTTPS for provisioning and file/OTA metadata.

Key takeaways

MQTT success is mostly topic architecture, QoS discipline, security, and reconnect strategy — not just “install a broker.”