RabbitMQ Exchanges: Key Models, Keys, and Bindings Made Easy 101

RabbitMQ is a robust, popular, and reliable message broker solution for routing messages asynchronously between systems and apps. Configuring the core modules of RabbitMQ — exchanges, queues, and bindings is easy, but understanding these three modules fit together and when to use one setting over another can seem relatively difficult. Whether your application is in the cloud or your own data center, RabbitMQ is a lightweight and potent tool for creating distributed software architectures that range from simple to complex.

In this blog, you’ll learn about key modules in RabbitMQ exchanges and how to use them to design your message broking system.

Table of Contents

• Prerequisites
• What is RabbitMQ?
  • Features of RabbitMQ
• RabbitMQ Exchange Types
  • RabbitMQ Exchange Type: Direct
  • RabbitMQ Exchange Type: Default
  • RabbitMQ Exchange Type: Topic
  • RabbitMQ Exchange Type: Fanout
  • RabbitMQ Exchange Type: Headers
  • RabbitMQ Exchange Type: Dead Letter
• RabbitMQ Queues
• RabbitMQ Bindings
• Conclusion

Prerequisites

• Understanding of message brokers

Understanding RabbitMQ

RabbitMQ is a message-queueing software where queues and binding keys are used to transfer a message(s) between applications. A message can have information about a process or task or a simple text message. The queue stores messages until a receiver connects and takes a message off the queue. The receiving application processes the message.

The message flow in RabbitMQ:

• The producer publishes a message to exchange and also specifies the type.
• The exchange is responsible for routing the message after receiving it. Depending on the exchange type, the exchange will consider various message attributes, such as the routing key.
• Bindings are created from the exchange to queues. There will be two bindings for two different queues, and the exchange will route the message into the queues depending on message attributes.
• The messages stay in the queue until a consumer handles them.
• The consumer handles the message.

Features of RabbitMQ

Following are the features of the RabbitMQ message queuing system:

• Open-source: RabbitMQ was originally developed by Cohesive FT, LShift, and LTD. It is owned by Pivotal Software Inc. and released under the Mozilla Public License. RabbitMQ enjoys freedom and flexibility as an open-source project written in Erlang and leverages Pivotal’s strength as a product. Developers and engineers can contribute enhancements and add-ons, and Pivotal can offer commercial support and stable home for product maturation.
• Platform and vendor-neutral: RabbitMQ implements Advanced Message Queuing Protocol (AMQP), a platform- and vendor-neutral system. Clients are available for all major computer platforms and almost any programming language.
• Lightweight: RabbitMQ is lightweight, and systems require less than 40MB of RAM to run the core application and plugins like the Management UI. However, adding messages to queues will increase their memory usage.
• Flexibility in controlling messaging trade-offs: RabbitMQ provides flexibility in controlling the trade-offs with message throughput and performance. It’s not a “one size fits all” application, and all messages can designate whether they should be persisted to disk before delivery. Queues in a cluster can span multiple servers to ensure no message loss in case of server failure.
• Third-party plugins: RabbitMQ has a flexible plugin system such as third-party plugins for storing messages directly into databases or using RabbitMQ for database writes.
• Client libraries for most modern languages: RabbitMQ is a compelling broker and has client libraries targeting most modern programming languages on multiple platforms. There’s no vendor or language lock-in when you write programs that talk to RabbitMQ. It’s the centerpiece of applications written in different languages. RabbitMQ provides a valuable bridge that allows languages such as Java, Ruby, C#, Python, and PHP to share data across operating systems and environments.

RabbitMQ Exchange Types

Messages in RabbitMQ are not published directly to a queue. Instead, the messages are published to an exchange responsible for routing the messages to the respective queues with the help of bindings and routing keys. A binding key is a link between a queue and an exchange. There are six types of exchanges in RabbitMQ:

RabbitMQ Exchange Type: Direct

In the direct exchange type in RabbitMQ Exchanges, a message goes to the queues whose binding key matches the message’s routing key. The direct exchange type uses a simple string identifier to distinguish messages published to the same exchange. When a new message arrives, the direct exchange will route it to the queue with the appropriate routing key. However, if the message routing key and binding keys don’t match, the message is discarded. If more than one queue has the same binding key, the direct exchange will broadcast the message to all matching queues.

RabbitMQ Exchange Type: Default  

The default exchange in RabbitMQ Exchanges is a pre-declared (empty string) direct exchange with no name. The default exchange will deliver the message to the queue whose name matches the routing key. Every queue is automatically hooked to the default exchange with a routing key similar to the queue name, making it a very useful tool for simple applications. For example, when declaring a queue with the name “search-indexing-online,” the AMQP 0-9-1 broker will bind it to the default exchange using the same name as the routing key (or binding key). Simply put, the default exchange makes it seem like users can deliver messages directly to queues, even though that is not what is technically happening.

RabbitMQ Exchange Type: Topic

The third type of RabbitMQ Exchange is Topic exchange and it is similar to direct exchange, but the routing is done according to the pattern. Instead of using a fixed routing key, the Topic exchange uses wildcards where messages are routed to one or multiple queues based on matching a message’s routing key and pattern. The routing key must consist of a list of words delimited by a period. The consumers specify which topics they would like to receive messages from. Then, the consumer creates a queue and sets up a binding to the exchange with a given routing pattern. All messages whose routing key matches the routing pattern are routed to the queue until the consumer handles the message.

RabbitMQ Exchange Type: Fanout

The fanout RabbitMQ exchange copies and routes the message to all queues bound to the exchange; it ignores all keys. This can be helpful when the message has to be sent to multiple queues to different consumers. For example, when a customer places an online order from a brand or retailer, you have to notify the warehouse, the cargo company, and the customer. With the fanout exchange, the message will be routed to all recipients. 

RabbitMQ Exchange Type: Headers

The next RabbitMQ Exchange type is a Headers Exchange. A headers exchange in RabbitMQ routes messages based on headers and optional values. It uses the message header attributes for routing, where users have to give a special argument named “x-match.” It is binding between exchange and queue and specifies if the system should match all headers or just one. The “x-match” property can have two values: “any” or “all.”

RabbitMQ Exchange Type: Dead Letter

The last type of RabbitMQ Exchange is Dead Letter. If there is no matching queue for the message, the system can republish the message to exchange with the dead letter option. RabbitMQ has “Dead Letter Exchange,” an AMQP extension that allows for capturing messages. Messages are termed not deliverable because one of the three reasons:

• A consumer negatively acknowledges the message using basic.reject or basic.nack with requeue parameter set to false.
• The message expires due to per-message TTL; or
• The message is dropped because its queue exceeded a length limit.

RabbitMQ Queues

Queues are similar to SMTP mailboxes, which store messages consumed by applications and forward them to consumers. Users will have to declare a queue before using it to store and forward messages unless it already exists. When the existing queue attributes are not the same as those in the declaration, a channel-level exception with code 406 (PRECONDITION_FAILED) will be raised.

Queues have several attributes associated with them:

• Name
• Exclusivity
• Durability
• Whether the queue is auto-deleted when no longer used
• Other metadata (sometimes called X-arguments)

RabbitMQ Bindings

A binding in RabbitMQ is an association between a queue and an exchange. Queues have to be bound to at least one exchange to receive messages from publishers. Bindings are rules for routing messages to queues. Suppose you have to instruct an exchange E to route messages to a queue S. For E to each S, the latter must be bound to E. Bindings may have an optional routing key attribute where the purpose of the routing key is to select specific messages published to an exchange to be routed to the bound queue.

To draw an analogy:

• The queue is like your destination in Chicago.
• Exchange is like O’Hare International Airport.
• Bindings are routes from O’Hare International Airport (Exchange) to your destination (Queue). There can be no or many ways to reach your destination.

Conclusion

RabbitMQ is an exciting technology enabling operational flexibility that’s challenging to achieve without its loosely coupled application architecture. By diving deep into RabbitMQ key modules in this article, you learned about how you can leverage its robust and powerful features. Using exchanges in RabbitMQ can extensively and appropriately simplify your queuing architecture.

However, as a Developer, extracting complex data from a diverse set of data sources like Databases, CRMs, Project management Tools, Streaming Services, and Marketing Platforms to your Database can seem to be quite challenging. If you are from non-technical background or are new in the game of data warehouse and analytics, Hevo Data can help!

Visit our Website to Explore Hevo

Hevo Data will automate your data transfer process, hence allowing you to focus on other aspects of your business like Analytics, Customer Management, etc. This platform allows you to transfer data from 100+ multiple sources to Cloud-based Data Warehouses like Snowflake, Google BigQuery, Amazon Redshift, etc. It will provide you with a hassle-free experience and make your work life much easier.

Want to take Hevo for a spin? Sign Up for a 14-day free trial and experience the feature-rich Hevo suite first hand.

You can also have a look at our unbeatable pricing that will help you choose the right plan for your business needs!