A lightweight, broker-mediated publish-subscribe messaging protocol running over TCP/IP, designed to minimize message overhead and support constrained devices and unreliable or low-bandwidth network conditions, commonly used for IoT telemetry and sensor data transport.

Key Points

Uses a publish-subscribe model — publishers send messages to a named topic without needing to know which subscribers, if any, are listening, and a central broker handles message distribution
Designed with a minimal header and message overhead specifically to suit constrained devices and low-bandwidth or high-latency links
Offers three quality-of-service levels (at-most-once, at-least-once, exactly-once delivery), letting an application choose the appropriate reliability/overhead tradeoff per message type
Includes a "last will and testament" mechanism, where a device can pre-register a message to be published automatically if it disconnects unexpectedly, useful for detecting silent device failures
Runs over TCP/IP (or, in constrained variants, alternative transports), making it broker-mediated rather than a direct device-to-device protocol

Concept

A device publishing data over MQTT sends it to a named topic on a central broker rather than to a specific recipient; any number of subscribers registered to that topic receive the message from the broker without the publisher needing any awareness of who, or how many, are listening. This decoupling is what makes MQTT well suited to IoT architectures where a sensor's data may need to reach a dashboard, a data lake, and an alerting system simultaneously, without the sensor itself needing to know about any of them.

Explainer

MQTT's minimal overhead and configurable quality-of-service levels are what let it work acceptably over the same constrained, intermittent links that LPWAN and cellular IoT technologies are built around — a two-byte fixed header and the ability to choose "at-most-once" delivery for high-frequency, loss-tolerant telemetry, where a missed reading is acceptable, keeps protocol overhead proportional to the constrained link it's often running over, rather than imposing the heavier framing of a general-purpose messaging protocol designed for broadband networks. This flexibility comes at the cost of centralization: because every message passes through a broker, broker availability and scaling become the practical bottleneck for MQTT-based architectures at scale, and broker placement — cloud-hosted versus deployed near the edge — becomes a real architectural decision balancing latency, resilience, and operational complexity. For CE verticals, MQTT's role is typically as the messaging layer sitting immediately behind whatever edge connectivity technology aggregates device data — a gateway collecting LoRaWAN or NB-IoT sensor readings commonly republishes that data as MQTT messages for downstream consumption, making MQTT the de facto lingua franca connecting diverse edge protocols to a common backend data pipeline.