Using an MQTT Broker? Here's Why You Need to Think About Scalability

There are several options for developing a message broker with full duplex functionalities and various supporting features. Some of these options are the use of a raw TCP socket, a raw UDP socket, AMQP and CoAP. Most of these alternatives have more limitations and complications than benefits, especially when compared to MQTT. This is where MQTT becomes the most appropriate, efficient and convenient choice, especially when building our own Internet of Things platform.

Remember that all of these protocols can coexist, and we could deploy them on the same cloud instance, if necessary. This means that, in the future, if you decide to use AMQP as well as MQTT, it's possible to integrate some or all of them. More importantly, we can link these channels with an additional plugin program so that there's a seamless communication from an application's and device's perspective.

Using an MQTT Broker

Fundamentally, MQTT is an asynchronous protocol and thus enables duplex communication with a lightweight burden on systems. It allows systems to run on low bandwidth and low power. Conversely, HTTP and similar protocols require relatively high bandwidth and power and are request-response in nature, which means that the client must always initiate communication.

In places where you want either party (server or client) to initiate communication, MQTT is the best choice. Moreover, if systems need to run on low data consumption, especially on batteries, for a long period, it's prudent to use MQTT. If the device needs to send or receive data frequently and at random, then MQTT also makes sense because it reduces a significant HTTP overhead.

If bandwidth and power is not a concern, then HTTP may be a better choice. It could also be a better choice when data sending or receiving frequency isn't high, which can block the resources sooner in the process.

Why and When to Use MQTT For IoT Messaging

In an application where live control or monitoring is required, MQTT is an obvious choice because it provides duplex, two-way communication abilities with the least amount of overhead.

You must be mindful of the fact that the workload of an MQTT-based the system can grow parabolically, which means that for each device added to the MQTT speaking network that has n devices in total, the load on the system becomes n squared n*n. The figure below explains this concept graphically.