Understand the protocols behind IoT messaging

This post is part 2 of the IoT messaging series

Parties in this series:

Part 2 – Understanding the protocols behind IoT messaging (you are here)
Part 3 – Building real-time IoT dashboards with LavinMQ and WebSockets
Part 4 – Visualizing IoT data dynamically through live dashboards
Part 5 – Securing and scaling IoT systems for reliability and performance

Humans need a common language to communicate. Devices and applications need the same thing. They use a set of rules, called protocols, so they can send and receive data in a way both sides understand.

In another post , we looked at a simple IoT data pipeline: LavinMQ→ Prometheus → Grafana. That post shows the overall architecture and how IoT devices send their data to LavinMQ. LavinMQ stores the incoming messages, Prometheus pulls those messages over HTTP, and Grafana uses the data to build dashboards.

I mention this because the diagram in that post helps show where each protocol is used. In this post, we focus on which protocol works better on the device side (IoT → LavinMQ) and which one fits the backend (LavinMQ → other services), and why that choice matters.

Choosing the right protocol matters because each part of the system has different needs. IoT devices have limited resources, like CPU and memory, and often run on unstable networks. Backend systems don’t have these limitations and usually need features like reliability, message routing, and scaling. If you use a protocol that doesn’t match the environment, you can end up with dropped messages, high resource usage, or a system that doesn’t scale well.

Before we continue: LavinMQ supports MQTT and AMQP along with other protocols. I focus on these two because they are widely used in messaging systems and are defined as open standards by OASIS, the group that maintains the MQTT and AMQP specifications.

MQTT on the device side

For the device side of our IoT setup, we used MQTT. MQTT fits well with this part of the system because it was designed for small, low-power devices and networks that may not always be stable.

According to the MQTT specification, MQTT is a lightweight publish/subscribe protocol made for constrained devices and low-bandwidth or high-latency networks.

Here are the main reasons MQTT worked well for us:

Lightweight

Many IoT devices have very little memory, slow processors, or run on batteries. MQTT keeps packet sizes small and avoids extra overhead, which helps devices send their data without using too many resources. AWS also highlights this advantage in its documentation.

Works on unstable networks

IoT devices often can connect over slow Wi-Fi, mobile networks, or remote links. MQTT handles reconnects with low overhead, making it more reliable when the network drops or slows down. The MQTT documentation specifically mentions this use case.

Simple topic-based communication

Devices publish to topics like – sensors/livingroom/temperature. They do not need to know which service will receive the data. This keeps the device code simple. An MQTT broker uses the publish/subscribe model, which is helpful for small devices because it removes the need for direct connections. Decoupling the sender from the receiver.

AMQP also works with LavinMQ, but it is heavier: larger packets, more metadata, bigger client libraries, and higher CPU and memory use. These features are useful, but mostly for backend systems, not for small sensors. For devices with limited resources, MQTT was a better fit.

AMQP on the backend

In our early testing, we used MQTT both at the edge and in the backend. Our goal at that stage was to send data end-to-end, and MQTT was enough for that.

Reliability is important on both sides. However devices are limited in resources such as CPU and memory, so they can't support heavier reliability features.

On the backend, we usually have much more CPU, memory, and storage available. This makes it possible to use AMQP’s stronger reliability features, such as:

Reliable message delivery
Sending the same message to multiple backend services
Retrying failed messages
Routing messages based on rules
Scaling consumers as the system grows

This is where AMQP is usually the better choice. Backend servers don’t have the resource limits that IoT devices do, so they can take advantage of AMQP’s extra features.

According to the RabbitMQ AMQP documentation, AMQP is designed for reliable communication, flexible routing, and enterprise-level messaging.

A common structure looks like this:

IoT Devices (MQTT) → LavinMQ → Backend Services (AMQP)

This lets each part of the system use the protocol that matches its needs.

Summary

We used MQTT everywhere in our simple testing setup, and it worked well. In production systems, it’s common to use MQTT on devices because it is lightweight and built for constrained hardware. On the backend, AMQP is often used when you need routing, durability, retries, and scaling - features that backend systems can support and AMQP was designed for.

👉 Next up:

Part 3 – Building real-time IoT dashboards with LavinMQ and WebSockets (coming soon)