Do You Really Need a Dedicated MQTT Broker for IoT?

MQTT makes it easy to send data from IoT devices. It's lightweight, works well with resource-constrained devices, and uses a publish/subscribe model that makes communication relatively simple.

But choosing MQTT is only part of the architectural decision.

What happens after your sensor data reaches the broker?

What if that data needs to be processed by backend workers, stored in a database, displayed on a dashboard, or forwarded to other services?

I started thinking about these questions while building an IoT demo using ESP32 devices.

I work with LavinMQ, an open-source message broker that supports both MQTT and AMQP. I wanted to explore whether using both protocols in one broker could simplify an IoT architecture.

Starting with a simple ESP32 sensor

My initial setup was straightforward:

• An ESP32 microcontroller
• A DHT11 temperature and humidity sensor
• Wi-Fi connectivity
• MQTT for publishing sensor readings
• LavinMQ as the message broker

Each device periodically publishes sensor readings to LavinMQ.

For example, a device might publish a message like this:

Topic:

sensors/device-01/temperature

Payload:

{
  "device_id": "device-01",
  "temperature": 24.5,
  "humidity": 52
}

A dashboard subscribes to the relevant MQTT topics and displays the readings in real time.

You can explore the live IoT demo to see how it works.

So far, this is a fairly typical MQTT application.

But things become more interesting when the application grows.

What happens when you have hundreds of devices?

Imagine expanding this setup from a handful of sensors to hundreds of devices.

As the system grows, the same sensor readings may need to serve several applications, each with different delivery and processing requirements.

For example:

• Monitoring dashboard: Displays live sensor readings.
• Data storage service: Stores historical measurements for analysis.
• Alerting service: Detects abnormal temperatures and triggers notifications.
• Backend workers: Process incoming measurements and perform additional operations.

These applications have different requirements.

A dashboard might only need the latest reading.

A backend worker might need to process messages reliably, acknowledge completed work, and retry failures.

MQTT works well for device communication, but backend processing often introduces additional messaging requirements.

This is where combining MQTT and AMQP becomes useful.

Using MQTT and AMQP together

LavinMQ supports both MQTT and AMQP.

This means IoT devices can communicate using MQTT while backend applications can use AMQP.

Conceptually, the architecture looks like this:

             ESP32 + DHT11
                  |
                  | MQTT PUBLISH
                  v
              LavinMQ
                  |
        +---------+----------+
        |                    |
        | MQTT               | AMQP
        v                    v
   Live Dashboard        AMQP Queue
                             |
                             v
                       Backend Workers
                             |
                             v
                      Data Processing

The interesting part is that devices don't need to know how the backend processes their messages.

They simply publish sensor readings.

Backend applications can consume messages using messaging patterns appropriate for their workloads.

A practical example

Imagine an ESP32 publishing a temperature reading to:

sensors/device-01/temperature

An MQTT subscriber receives the reading and updates the dashboard.

Meanwhile, with the appropriate routing and queue configuration, an AMQP consumer can process the same sensor data.

For example, a backend worker could:

1. Receive the temperature reading from an AMQP queue.
2. Check whether the temperature exceeds a configured threshold.
3. Store the reading in a database or trigger an alert.
4. Acknowledge the message after successful processing.

If the worker fails before acknowledging the message, the broker can make it available for redelivery, depending on the queue and consumer configuration.

AMQP provides features such as acknowledgments, queues, routing, and consumer prefetch, which are useful for backend processing.

Of course, supporting both protocols doesn't automatically guarantee that every MQTT publication reaches the intended AMQP consumer. The appropriate routing and queue configuration are still required.

But the ESP32 doesn't need to know whether its message is being consumed by an MQTT dashboard or an AMQP worker.

The device publishes once, and the backend architecture determines how the data is processed.

Do you really need a dedicated MQTT broker?

Not necessarily.

Dedicated MQTT brokers such as Mosquitto are excellent choices for many IoT applications.

If your system primarily needs MQTT publish/subscribe communication, a dedicated MQTT broker may be exactly what you need.

LavinMQ offers a different architectural option: MQTT for device communication and AMQP for backend messaging, without necessarily introducing a separate broker.

That can be useful when IoT devices need to communicate with backend services that already rely on AMQP.

Neither approach is universally better.

The right choice depends on your application's requirements, protocol compatibility, operational complexity, and reliability needs.

Try it yourself

Want to build your own IoT project using ESP32, MQTT, and LavinMQ?

Interested in trying this with real hardware? We're happy to hear from developers who want to experiment with our ESP32 IoT devices.

You can request an IoT device by emailing us at [e-mail] or leaving a comment below.

Once you have your device, follow our step-by-step tutorial:

Build a Real-Time Temperature Monitoring System with LavinMQ and IoT

What I'm exploring next

I'm planning to compare LavinMQ and Mosquitto using real ESP32 devices.

I'm particularly interested in understanding

• How the brokers handle increasing numbers of connected devices.
• What happens when subscribers become slow or connections are interrupted.
• When a multiprotocol broker simplifies an IoT architecture.

Rather than focusing only on which broker is faster, I want to explore how they behave under equivalent workloads and what trade-offs matter in real IoT applications.

I'll share the results in a follow-up post.

What does your IoT architecture look like?

If you're building IoT applications in production, I'd be curious to hear about your experience.

What happens to your MQTT messages after they reach the broker?

Do you process everything through MQTT, or do you forward the data to another messaging system?

I'd love to hear how you've designed your architecture and what trade-offs you've encountered.