If you've been researching IoT development for more than five minutes, you've encountered MQTT. It's the protocol that underlies everything from your smart home devices to industrial SCADA systems to connected vehicles. But what exactly is MQTT, why did it win out over competing protocols, and how should you use it in your IoT architecture?
This guide cuts through the jargon and gives you a practical, complete understanding of MQTT — from its core concepts to production deployment considerations.
What Is MQTT?
MQTT (Message Queuing Telemetry Transport) is a lightweight publish-subscribe messaging protocol designed for constrained devices and unreliable networks. It was originally developed by Andy Stanford-Clark at IBM and Arlen Nipper in 1999 for monitoring oil pipelines via satellite — a use case that demanded extreme efficiency and tolerance for connectivity gaps.
MQTT became an OASIS standard in 2014 and has since become the de facto standard for IoT messaging. It runs over TCP/IP and is available in two major versions: MQTT 3.1.1 (widely deployed) and MQTT 5.0 (adds advanced features like message expiry, reason codes, and shared subscriptions).
Core Concepts: Publish, Subscribe, and Broker
MQTT uses a publish-subscribe (pub-sub) model — a significant departure from traditional request-response HTTP. Understanding this model is key to working effectively with MQTT.
The Broker
The broker is a central server that receives all messages and routes them to the right subscribers. Popular brokers include Eclipse Mosquitto (open source), HiveMQ, EMQX, and managed services like AWS IoT Core. The broker decouples publishers from subscribers — they never communicate directly.
Topics
Messages are published to named topics, which form a hierarchical namespace using the forward slash as a separator. For example: factory/line1/sensor/temperature. Topics are flexible — you define them based on your system's needs. Wildcards let subscribers listen to multiple topics at once: factory/+/sensor/# matches all sensor readings across all production lines.
Publishers and Subscribers
Any MQTT client can publish messages to topics or subscribe to them (or both). A temperature sensor publishes to building/floor3/hvac/temp. A dashboard application subscribes to that topic and updates in real time. Multiple subscribers can receive the same message simultaneously.
Why MQTT Is Perfect for IoT
Minimal Protocol Overhead
The smallest MQTT packet is just 2 bytes. Compare this to HTTP, where headers alone can be 500+ bytes. This matters enormously for devices sending thousands of small readings per day over metered cellular connections. Lower overhead means lower data costs and longer battery life.
Quality of Service (QoS) Levels
MQTT supports three QoS levels that let you trade off reliability against overhead based on your use case:
- QoS 0 — At most once: Fire and forget. No acknowledgement. Best for high-frequency, loss-tolerant sensor data (e.g., temperature readings every second).
- QoS 1 — At least once: Message is acknowledged; may be delivered multiple times. Best for most IoT telemetry.
- QoS 2 — Exactly once: Four-way handshake guarantees single delivery. Best for commands or billing-critical data.
Persistent Sessions and Clean Sessions
Devices with unreliable connectivity can connect with persistent sessions. The broker queues messages for the device while it's offline and delivers them when it reconnects. This is invaluable for field devices on cellular networks that regularly lose connectivity in areas with poor coverage.
Last Will and Testament (LWT)
A device can register a "last will" message with the broker when it connects. If the device disconnects unexpectedly (power loss, network failure), the broker automatically publishes the last will message to a designated topic. This is how monitoring systems detect device failures in real time without polling.
"MQTT's genius is its simplicity. The spec that powers billions of devices worldwide is small enough to read in an afternoon — and that simplicity is a feature, not a limitation."
MQTT Security: What You Must Implement
Out of the box, MQTT has minimal built-in security. A production deployment requires explicit security configuration:
- TLS encryption: Run MQTT over TLS (often called MQTTS, port 8883) to encrypt all traffic. Never use unencrypted MQTT (port 1883) in production.
- Authentication: Use client certificates (X.509), username/password at minimum, or OAuth 2.0 tokens for modern deployments.
- Authorization: Configure topic-level access control — a device should only be able to publish to its own topics, not read commands destined for other devices.
- Broker hardening: Disable anonymous access, set message size limits, and configure rate limiting to prevent flood attacks.
MQTT 5.0: What's New
MQTT 5.0 adds significant new capabilities over 3.1.1:
- Reason codes: Detailed error information on connections, subscriptions, and publish operations
- Message expiry: Published messages automatically expire after a configurable interval
- Shared subscriptions: Load-balance message delivery across a group of subscribers — essential for scalable consumer microservices
- User properties: Attach arbitrary key-value metadata to any message
- Response topics: Built-in request-response pattern support
Choosing the Right MQTT Broker for Production
For development and small-scale production: Eclipse Mosquitto is lightweight, well-documented, and runs anywhere. For enterprise scale: EMQX (handles 100M+ connections on a cluster) or HiveMQ (enterprise features, excellent Kubernetes support). For cloud-managed: AWS IoT Core, Azure IoT Hub, and Google Cloud IoT Core all use MQTT and handle the infrastructure scaling for you.
If you're building an IoT system and want to get the messaging architecture right from the start, talk to our team. We design and deploy robust MQTT-based IoT pipelines across industries.
