Exchange to exchange bindings in RabbitMQ

Using the RabbitMQ exchange to exchange binding allows such topologies to run smoothly.

This article examines exchange to exchange binding in depth. You will learn how to build flexible messaging systems without additional complexity.

Bindings in RabbitMQ

The glue that holds RabbitMQ together is the binding. A binding determines how messages are routed within the broker. Essentially, a binding is a directive that tells an exchange how to send data to a queue or another exchange.

The binding also contains routing keys and arguments that customize message passing. An x-match header, for example, specifies whether all or some specified headers must match to pass a message to a queue or exchange.

Exchange Binding in RabbitMQ

Binding exchanges in RabbitMQ work the same way as they do with queues, with the only difference being the command.

Run the following to connect the parent_exchange with the corresponding child_exchange:

conn_str = "amqp://:@127.0.0.1:5432/vhost"
params = pika.URLParameters(conn_str)
connection = pika.BlockingConnection(params)
channel = connection.channel()
channel.exchange_declare(exchange='parent_exchange', exchange_type='fanout')
channel.exchange_declare(exchange='child_exchange', exchange_type='direct')
channel.exchange_bind(destination='child_exchange', source='parent_exchange', routing_key='routing_key')
channel.close()
connection.close()

Any message sent to the parent_exchange now routes to the child_exchange based on the parent_exchange’s configuration. The message passes to a single bound object when the routing algorithm is set to direct and to each bound object when set to fanout. Additional arguments can be passed with this method as well. At a minimum, exchange binding supports the no-wait parameter, which tells the broker not to respond to the request. Queue specific parameters are not accepted.

Building Complex Topologies in RabbitMQ

Binding exchanges allow you to create elaborate topologies. However, we suggest that you avoid using the federation plugin and more complicated custom-built mechanisms when building with binding exchanges, as it makes the overall system more cumbersome.

This type of binding works well when:

• Needing to serve the same message differently to different queues
• Saving messages for exchanges that are deleted automatically
• Attaching many topics to exchanges

Topics require exchanges to decipher which queue to route a message to based on a non-arbitrary key. Keep in mind that more bindings require more processing time, but adding exchanges at scale can help improve performance.

Exchanges use memory, and having too many will slow the message passing system. For large projects, it is best to cluster brokers and binding exchanges.

Using RabbitMQ Exchange to Exchange Binding

RabbitMQ exchange to exchange binding allows you to create complex topologies without federating brokers. The binding works well when using topics, automatically deleted exchanges, or serving messages to queues with different needs.

Code example in Python:

channel.exchange_bind(destination='destination_exchange',source='source_exchange')

Create a free broker on CloudAMQP to test the exchange to exchange bindings in an easy way.