RabbitMQ

Routing Keys & Bindings

Wire producers to consumers declaratively through binding keys instead of hardcoded destinations.

A binding is the link between an exchange and a queue, optionally qualified by a binding key. When a producer publishes, it sets a routing key on the message. The exchange compares the routing key against the bindings (according to the exchange type) to decide delivery. This indirection is what decouples producers from consumers: a producer just labels a message, and operators can rewire who receives it by adding or removing bindings — no producer code change.

Routing keys are like email subject-line conventions and bindings are inbox filter rules: senders just label the subject, and each recipient sets up filters to pull the labels they care about. Change a filter and you change what you receive — the sender never knows.

Key Concepts

1
Routing keys are typically dot-delimited hierarchies (region.service.severity, e.g. eu.payments.error) so topic exchanges can match slices of the hierarchy. One queue can have several bindings, and several queues can bind the same key, enabling both selective routing and fan-out from one exchange.
2
Designing a clear routing-key taxonomy up front is one of the highest-leverage decisions in a RabbitMQ topology.