MQTT in one sentence
MQTT is a lightweight publish/subscribe messaging protocol designed for unreliable networks and constrained devices. Instead of clients talking directly to each other, they publish messages to a broker, and subscribers receive messages for topics they care about.
This model decouples senders and receivers. Devices do not need to know who is listening, and listeners do not need to know who is sending.
Publish/subscribe vs request/response
HTTP is request/response: a client asks, the server answers. MQTT is event-based: publishers emit messages, subscribers receive them asynchronously.
That makes MQTT ideal for telemetry, sensor data, and real-time events where many clients need the same data stream.
The broker as the hub
In MQTT, the broker is the central router. It handles subscriptions, permissions, and message delivery.
Because all messages flow through the broker, it becomes the place to enforce security, retention, and quality of service.
Topics and hierarchies
Topics are hierarchical strings that act like channels. `home/kitchen/temperature` is a common style.
Subscribers can use wildcards to listen to multiple topics, which makes MQTT flexible for large fleets of devices.
QoS levels: reliability choices
MQTT has three Quality of Service levels. QoS 0 is fire-and-forget, QoS 1 ensures delivery at least once, QoS 2 guarantees exactly once.
Higher QoS means more overhead. Choose the level that matches the business impact of lost or duplicated messages.
Sessions, retained messages, and last will
MQTT supports persistent sessions and retained messages so late subscribers can receive the latest state.
The Last Will and Testament feature lets the broker publish a message if a client disconnects unexpectedly.
When MQTT is a good fit
MQTT shines in IoT, fleet monitoring, smart homes, and any system with many devices sending small messages frequently.
It is also useful when bandwidth is limited or connections are unreliable.
When MQTT is not a good fit
MQTT is not ideal for large payloads, complex request/response flows, or public web APIs.
If your use case is CRUD over resources, HTTP/REST may be a better default.