MQTT is the most common data messaging protocol associated with IoT. It is supported by all the major cloud infrastructure providers (AWS, Microsoft, and Google). And it is most likely the protocol that is being used to deliver your data. It was designed for minimal power loss and minimal bandwidth requirements. It originated to support remote oil and gas use cases over satellite communication networks. It translated well into the broader IoT world as it developed in recent years.

At its heart, it is similar in concept to a messaging queue architecture but, despite the name, not a traditional queue. This means that new data comes into an intermediary broker as a message, and then it is delivered to the end server. The IoT device is called the publisher and the ending server is called the subscriber. Both connect to the broker but never to each other.

MQTT follows the publish/subscribe architecture pattern or pub/sub, but it is implemented differently than a traditional message queue. It is a queue of one, in that the message for the topic is replaced with the latest data instead of being added to an expanding line of messages, as with a traditional message queue.

The message on the broker exists regardless of if the publisher or the subscriber is online and willing to interact with it. This makes it robust against intermittent connections (intentional or unintentional). The subscriber does not have to wait until the publisher is awake and willing to chat. The publisher can send a message without caring about the details of who is willing and able to receive it.

The broker has no knowledge of, nor does it care, what is inside the message. The message is published by the device to an address on the broker known as a topic. Topics are a key concept in MQTT and will be discussed in detail later on.

Differences between MQTT queue (topics) and traditional message queues are as follows:

• Topics do not have to be created ahead of time: They are flexible and can be created on the fly. Traditional message queues have to be created and named explicitly before they can receive messages.
• Topics do not keep all messages until they are consumed: Traditional queues keep everything until it has been consumed by a subscriber. Topics just replace old messages with new ones.
• Topics can have multiple subscribers receiving the same message: Traditional message queues are designed for a message to be consumed by one client.
• Messages do not require a subscriber: Traditional message queues require someone to consume them. Otherwise, it will eventually fill up and be unable to accept more items.

MQTT is intended to be very light overhead. A device can switch on periodically, connect to the broker, send a message, then go back to sleep without worrying about if the subscriber is able to receive it right away.

However, most implementations keep a persistent connection. Communication tends to be near real time in practice.