AMQP vs MQTT: Comparing Instant Messaging Protocols
Finding the right instant messaging protocol for your project is a daunting task.
There are a ton of chat protocols to choose from. And each protocol comes with its own laundry-list of benefits and drawbacks.
While doing your research, you may have stumbled upon the AMQP and MQTT protocols. These two can seem pretty similar at first glance, which can make it hard to determine which one best suits your needs.
In this article we are comparing AMQP vs. MQTT to figure out which protocol is best for you.
Let’s get started.
What are AMQP and MQTT?
As we like to say, it’s hard to compare two things without first knowing what they are.
So, let's start with a quick overview of both AMQP and MQTT.
Both AMQP and MQTT are open-source, standardized protocols for asynchronous messaging.
AMQP (Advanced Message Queuing Protocol) is a binary messaging protocol designed to effectively support a wide range of messaging applications and communication patterns. Its use of a streamed binary messaging system allows for the interoperability of clients from different vendors. This makes AMQP shine in multi-client environments.
MQTT (MQ Telemetry Transport) is a lightweight messaging protocol designed for high-latency, low-bandwidth, and unreliable networks. It consumes very little power on the device it’s running on. Due to its low overhead, MQTT is most often used in an embedded environment for machine-to-machine communication. Its use is prevalent in industries such as automotive, manufacturing, telecommunications, and smart homes.
It's important to look at the origination and original purpose of messaging protocols, as their origin stories often dictate their paths of development and adoption. You can often tie things like feature and design choices back to the original goal for the protocol. In this case, the two protocols originated in different industries, for different purposes.
AMQP was born in the financial industry. The finance community wanted a way to avoid dealing with the licensing headaches of proprietary systems. So, they created AMQP to provide an open-source method of communicating the vast amount of market data to and from financial systems. Development was customer-driven.
MQTT, on the other hand, was born in the technology industry. It was created by IBM and its partners to allow the MQSeries of products to work efficiently on smaller devices. Unlike AMQP, MQTT’s development was vendor-driven.
What Role Does Each Play in the Overall Chat Architecture?
Both protocols play the same role in an application—allowing programs to send and receive asynchronous messages no matter what operating systems, hardware, and programming languages are used.
Because they fulfill the same function, AMQP and MQTT are most often used independent of each other. However, if you have a complex system with many different types of devices and connections, both protocols can be effectively leveraged to work together by playing on their individual strengths.
As mentioned above, despite both performing the same function, AMQP and MQTT are designed for different purposes. MQTT is ideal for a large number of size-constrained devices to send small messages over a low-bandwidth network. AMQP, on the other hand, is designed to be able to allow for the full suite of messaging patterns and handle any type of scenario.
AMQP vs. MQTT: Strengths and Weaknesses
Now that we have a better understanding of the role each protocol plays, let’s compare AMQP and MQTT in terms of the features you may be looking for in a messaging protocol.
Security is almost always a top concern when choosing a messaging protocol. While it’s a moving target and nothing is 100% secure, integrated security features are a great plus to have.
Regarding connection security, both AMQP and MQTT integrate with TLS (Transport Layer Security), which encrypts the data on transfer. In addition to that, AMQP offers SASL (Simple Authentication Security Layer), which allows for a secure authentication handshake between client and server. MQTT doesn’t offer SASL out of the box, but it can be added manually.
When it comes to user security, MQTT requires short usernames and passwords. Unfortunately, these don’t provide enough security for the modern world of intensive brute-force attacks. And, since this policy is built into the protocol, you'll have to cross your fingers and hope they eventually address the security weakness via a new protocol version. AMQP, on the other hand, uses SASL to allow you to choose whatever type of security measures you find necessary.
In matters of security, AMQP has the upper hand.
Ease of Implementation
As a smaller, simpler protocol, MQTT is easier to implement than AMQP. At least, it would be easier to implement—if it weren't for open-source libraries.
Both protocols are open-source, which has resulted in the creation of several open-source implementation libraries for each protocol. No matter which operating system or language you choose for your chat app, you’ll be able to find an open-source library that makes implementing either protocol a breeze.
The existence of these open-source implementation libraries makes comparing ease of implementation a wash.
AMQP is a layered protocol. This means that a change in one layer is isolated from the rest, which makes extending the protocol easy. This also means that any future extensions are automatically backward-compatible. MQTT is not layered. So, any changes in the protocol require a completely new version.
AMQP is therefore the winner in regards to extensibility.
When it comes to messaging applications, there are two critical components of reliability: deliverability and the handling of broken connections. Let's start with deliverability.
Your end users need to be able to trust that their messages are being delivered. But that’s not all. They also have to be confident that their messages are received just once, as duplicate messages can overload the client, cause loss of information, and create false data. And finally, they want to know that their messages are being received in the right order.
Both AMQP and MQTT claim to be very reliable in their deliverability. They both offer three QoS (Quality of Service) levels. (The more QoS levels, the more reliable it is.) The three QoS levels are:
At most once (0): The lowest QoS level, here the recipient does not acknowledge receiving the message and the message is not stored and resent by the sender. There is no guarantee of delivery.
At least once (1): Level 1, the sender stores the message until it receives a ping from the receiver acknowledging delivery. Level 1 guarantees that the message is delivered at least once. But, on level 1 it is possible that a message gets sent and delivered multiple times. This level doesn’t guarantee the correct ordering of messages.
Exactly once (2): The highest QoS that MQTT and AMQP offer, this is the safest QoS level. It is also the slowest QoS level. It guarantees that the recipient will receive a message just once and that they'll be in the correct order. This is achieved with a four-part handshake between sender and recipient.
Now, on to broken connections. When a connection between client and server is broken on an MQTT protocol, a “Last Will” message is sent to the server. This allows the server to alert other clients that a connection was lost. On an AMQP protocol, you can specify “forwarding addresses” where messages will be sent if a connection is interrupted or unexpectedly dies. Both protocols handle broken connections, but AMQP does it more gracefully.
AMQP is slightly more reliable than MQTT when it comes to broken connections but they are on equal footing when it comes to deliverability.
MQTT only supports one type of messaging pattern: publish-subscribe messaging to topics. An MQTT client can either publish or subscribe to a “message topic”. When the client publishes a message to a broker it contains a message topic. When the broker receives the published messages, it uses the message topic to determine which other clients are subscribed to that specific topic. It then routes the message to those clients.
AMQP is much more flexible. It allows almost any form of messaging pattern, including classic message queues, publish-subscribe, round robin, and store-and-forward. It also allows numerous combinations of these patterns. And, AMQP uses message meta-data to support message grouping.
AMQP is the clear winner when it comes to the implementation of different types of messaging patterns.
Pros & Cons of AMQP vs. MQTT
Okay, now that we've compared each protocol through the lens of vital features, let's summarize:
Pros of AMQP vs. MQTT
Cons of AMQP vs. MQTT
Usage Examples of MQTT and AMQP
MQTT and AMQP are both widely used for commercial products.
While originally designed for embedded devices, MQTT has evolved over time. It's now even used for social apps. Facebook Messenger and Instagram both use MQTT for their mobile chat functionality.
Outside of chat and social apps, MQTT is used extensively in the IoT world. Amazon Web Services, IBM Watson, and Microsoft Azure all use MQTT as their main communication protocol, though most also support AMQP.
While AMQP doesn’t share MQTT’s popularity in the social media space, it more than makes up for it in the commercial industries. It’s widely used in critical systems in the financial, telecommunications, defense, manufacturing, internet, and cloud computing industries.
JPMorgan sends over a billion AMQP messages each day which connect their many complex financial systems. Other companies that rely on AMQP for their day-to-day operations include Google, NASA, Mozilla, AT&T, IBM, and the National Science Foundation. Obviously, this list is not exhaustive. In fact, there are over 500 commercial users of AMQP.
Conclusion: which protocol should you pick?
Choosing between AMQP and MQTT is not an easy task. The winner will be the one that fits your project's specific requirements.
If you need to support multiple messaging patterns, or anything other than the publish-subscribe pattern, AMQP is the protocol for you.
If you need to handle a high-latency, low-bandwidth environment, then MQTT is the better choice.
If extensibility of the protocol is a must-have, then AMQP is the clear choice.
If security is high on your priority list, AMQP is the better choice as it has a few more built-in security features.
If you’re working with small embedded devices that send telemetry data, MQTT is a no-brainer.
Also, keep in mind that AMQP and MQTT are not the only two messaging protocols to choose from. There are plenty of other communication protocols. For example, maybe Websockets or XMPP would better suit your needs.
To learn more about these other messaging protocols, check out the following resources:
Cosette Cressler is a passionate content marketer specializing in SaaS, technology, careers, productivity, entrepreneurship and self-development. She helps grow businesses of all sizes by creating consistent, digestible content that captures attention and drives action.