MQTT

Definition: A lightweight publish-subscribe messaging protocol designed for constrained IoT devices and unreliable networks, using far less overhead than typical HTTP requests.

How It Works

Devices publish messages to named “topics” (a hierarchical string like home/livingroom/temperature) rather than sending directly to a specific recipient, similar in spirit to message queue patterns
Other devices or services subscribe to topics they care about, and receive messages automatically as they’re published, including wildcard subscriptions (home/+/temperature matches any room)
A central broker (like Mosquitto, HiveMQ, or a cloud IoT service) routes every published message to every current subscriber of that topic, publishers and subscribers never talk to each other directly
Designed to be extremely lightweight: a minimal MQTT packet header is just 2 bytes, works over unreliable, high-latency, or low-bandwidth connections where HTTP’s overhead would be wasteful
Three Quality of Service (QoS) levels control delivery guarantees: QoS 0 (at most once, fire and forget), QoS 1 (at least once, possible duplicates), QoS 2 (exactly once, most overhead)
A persistent TCP connection stays open between client and broker, with periodic keep-alive pings, so the broker can detect a disconnected device quickly instead of waiting for a request that never comes
Clean vs persistent sessions control what the broker remembers about a client between connections: a persistent session preserves subscriptions and queued QoS 1/2 messages across a brief disconnect, a clean session starts fresh every time

Under the Hood

The sensor never knows the dashboard exists, and the dashboard never knows the sensor exists, both only know about the broker and the topic name, which is the entire point of the publish-subscribe model.

Worked example 1: QoS level behavior under a dropped connection

Given: a sensor publishes a reading at QoS 1 (at least once), and its connection to the broker drops right after sending but before the broker’s acknowledgment (PUBACK) arrives back
Step: because the sensor never received the PUBACK, it assumes the message might not have arrived and re-sends the same message once the connection is restored
Step: the broker, having actually received the original message just fine, now receives it a second time and delivers it to subscribers twice
Answer: this is exactly what “at least once” means, the message is guaranteed to arrive, but a subscriber might see a duplicate; applications using QoS 1 need to be able to tolerate or de-duplicate repeated messages, which is why QoS 1 (not QoS 2) is the most common real-world default, trading perfect exactness for lower overhead

Worked example 2: bandwidth comparison against HTTP

Given: a battery-powered sensor sends a small temperature reading (a few bytes of payload) once every 30 seconds
Step: a typical HTTP POST request carries several hundred bytes of headers (method, host, user-agent, content-type, connection handling) on top of the payload, and re-establishes a TCP connection (and often TLS handshake) for each request unless carefully configured to keep-alive
Step: MQTT keeps one persistent connection open and sends a minimal fixed header (as little as 2 bytes) plus topic and payload for each publish, with no repeated handshake overhead per message
Answer: over a day of 2,880 messages (one every 30 seconds), MQTT’s persistent-connection overhead is dramatically lower than repeated HTTP requests, which directly translates into meaningfully longer battery life for battery-powered sensors on constrained networks

Worked example 3: QoS 2 handshake overhead

Given: a payment-critical sensor reading must be delivered exactly once, using QoS 2
Step: QoS 2 requires a four-packet handshake per message: PUBLISH → PUBREC (broker confirms receipt) → PUBREL (sender confirms it can release) → PUBCOMP (broker confirms completion)
Step: compared to QoS 1’s two-packet handshake (PUBLISH → PUBACK), QoS 2 roughly doubles the round trips needed per message
Answer: on a high-latency or lossy connection, that extra round-trip cost can meaningfully slow throughput, which is why QoS 2 is reserved for cases where an exact duplicate would actually cause harm (a financial transaction, a one-time actuator command), not used as a default “safest” setting for ordinary sensor data

MQTT Message Anatomy

Field	Purpose	Example
Topic	Hierarchical string identifying the data channel	`factory/line3/temp`
Payload	The actual message content, any binary or text data	`21.7`
QoS	Delivery guarantee level (0, 1, or 2)	`1`
Retain flag	If set, the broker stores this message and delivers it immediately to any new subscriber	`true`
Last Will and Testament	Message the broker auto-publishes if this client disconnects unexpectedly	`factory/line3/status = offline`

Why It Matters

HTTP’s overhead, headers, connection setup, request/response pattern, is often too heavy for battery-powered sensors sending tiny amounts of data over spotty connections, MQTT is built specifically for that constraint
The publish-subscribe pattern decouples producers from consumers entirely, a new dashboard can start listening to existing sensor data without the sensors needing any code change or awareness of it
Retained messages and “last will and testament” (a message the broker sends automatically if a device disconnects unexpectedly) make MQTT well suited for reporting device presence/absence, not just data values

Common Pitfalls

Using MQTT for scenarios that actually need a request/response pattern, it’s built for publish/subscribe, not for “ask a device a question and wait for its answer” (though request/response patterns can be built on top of it with reply topics)
Not securing the broker properly, an exposed MQTT broker without authentication or TLS can let anyone read or publish to topics they shouldn’t have access to
Choosing QoS 2 by default “to be safe” without understanding its higher overhead (a four-step handshake per message), when QoS 1 is sufficient for most applications that can tolerate occasional duplicates
Designing overly broad topic hierarchies or overusing wildcard subscriptions, causing a subscriber to receive far more traffic than it actually needs to process
Forgetting to configure a Last Will and Testament message, missing the chance to have the broker automatically notify other clients when a device disconnects unexpectedly (power loss, network failure) rather than silently going quiet
Treating the broker as infinitely scalable without capacity planning, a single broker instance has real limits on concurrent connections and message throughput that need monitoring in production
Publishing large payloads (images, full log files) over MQTT when it was designed for small, frequent messages, better handled by a separate bulk transfer mechanism triggered by an MQTT message
Not setting an appropriate keep-alive interval, too long delays detecting a dead connection, too short wastes bandwidth and battery on unnecessary ping traffic

Comparison

Protocol	Model	Overhead	Typical use
MQTT	Publish-subscribe over persistent TCP	Very low (2-byte minimum header)	Constrained IoT sensors, mobile push-style updates
HTTP/REST	Request-response	Higher (headers, connection setup per request)	Web APIs, request-driven interactions
CoAP	Request-response, UDP-based	Low, but no persistent connection or broker	Very constrained devices without a broker infrastructure
WebSocket	Persistent bidirectional connection	Low after initial handshake	Real-time web applications, browser-based clients
AMQP	Message queue with routing, exchanges, and acknowledgments	Higher, more feature-rich	Enterprise messaging, complex routing needs

Example

A fleet of temperature sensors publishes readings to an MQTT topic (factory/line3/temp) every 30 seconds using QoS 1; a dashboard service and an alerting service both subscribe to that same topic independently, receiving every reading without the sensors needing to know either service exists. Eclipse Mosquitto is a widely used open-source MQTT broker for self-hosting, while AWS IoT Core, Azure IoT Hub, and HiveMQ Cloud are common managed broker services for production deployments at scale.

Eclipse Mosquitto: lightweight, self-hosted, common on Raspberry Pi and local networks
AWS IoT Core / Azure IoT Hub: managed, cloud-scale brokers integrated with each provider’s broader IoT device management tooling
HiveMQ: commercial and cloud-hosted broker aimed at large-scale enterprise MQTT deployments

Common Interview Questions

What’s the core architectural difference between MQTT and HTTP? — MQTT is publish-subscribe through a broker over a persistent connection; HTTP is request-response, typically a new connection or exchange per interaction
Explain the three MQTT QoS levels — QoS 0 sends once with no acknowledgment (may be lost), QoS 1 guarantees delivery but may duplicate, QoS 2 guarantees exactly-once delivery at the cost of a four-step handshake per message
Why is MQTT considered well-suited for IoT specifically? — its minimal packet overhead, persistent connection model, and tolerance for unreliable networks match the constraints of battery-powered, bandwidth-limited devices far better than HTTP does
What’s a Last Will and Testament message in MQTT? — a message a client registers with the broker at connect time, which the broker automatically publishes on that client’s behalf if the connection drops unexpectedly, letting other clients detect the disconnection
How would you secure an MQTT deployment in production? — TLS for transport encryption, username/password or certificate-based client authentication, and access control lists restricting which topics each client can publish to or subscribe to
What’s a retained message used for? — giving a newly connecting subscriber the most recent known value on a topic immediately, without waiting for the next publish, useful for things like “current device status” that shouldn’t appear blank until the next update
Why does MQTT use a hierarchical topic structure with wildcards instead of flat topic names? — it lets subscribers express broad or narrow interest naturally (home/+/temperature for all rooms, home/kitchen/# for everything in one room) without the broker needing any special-case logic

FAQ

Does MQTT require the internet, or can it run entirely on a local network? — either, a broker can run fully offline on a local network (common in factories) or be a cloud-hosted service, MQTT itself doesn’t care which
What happens to a published message if no one is subscribed to that topic yet? — by default it’s simply dropped, unless the publisher sets the “retain” flag, in which case the broker stores the most recent message on that topic and delivers it immediately to any client that subscribes later
Can MQTT handle two-way communication, like sending a command to a device? — yes, a device can subscribe to its own command topic (device/123/commands) while publishing its data to a separate topic, letting the same connection carry traffic in both directions
Is MQTT encrypted by default? — no, plain MQTT is unencrypted; MQTT over TLS (often on port 8883) is the standard way to add transport encryption, and production deployments should use it
How does MQTT compare to plain WebSockets for real-time apps? — MQTT adds a structured topic/subscription model and QoS guarantees on top of a persistent connection, where raw WebSockets just give you a bidirectional pipe and leave message routing and delivery guarantees to the application

Broker Deployment Notes

Self-hosted brokers (Mosquitto) give full control over data and infrastructure but require the operator to handle scaling, uptime, and security patching
Managed cloud brokers (AWS IoT Core, Azure IoT Hub, HiveMQ Cloud) trade some control for built-in scaling, device fleet management, and integration with the provider’s broader cloud services
Broker clustering spreads client connections and topic routing across multiple broker nodes, needed once a single broker instance’s connection or throughput limits are reached

Topic Design Note

Well-designed topic hierarchies mirror the physical or logical structure of the deployment (site/building/floor/room/sensor-type), making wildcard subscriptions meaningful and access control lists straightforward to write, while a flat or inconsistent topic naming scheme makes both far harder to manage as a deployment grows past a handful of devices.

Referenced by

Dig deeper

Spot an error in this note?