RabbitMQ
Wildcard Usage
Routing Key
Binding Key
Message Queuing

RabbitMQ - Wildcard in routing key vs binding key

System Design practice on Codemia

Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.

Practice system design

RabbitMQ, a widely used open-source message broker, supports complex routing schemes to manage and direct messages between producers and consumers. One of the powerful features of RabbitMQ in managing message distribution is the use of routing keys and binding keys, especially in the context of topics exchanges. In such exchanges, messages are routed to queues based on wildcard-pattern matching between the binding keys specified by the queues and the routing keys specified in the sent messages.

Understanding Routing Keys and Binding Keys

A routing key is a message attribute the producer adds to the message. This key describes the route a message should take when it hits an exchange. A binding key, on the other hand, is used to define the relationship (or binding) between a queue and an exchange.

Topic Exchange Mechanism

In the case of the topics exchange, both routing keys and binding keys allow the use of wildcard characters. These characters include:

  • * (asterisk) which matches exactly one word.
  • # (hash) which matches zero or more words.

Here, a "word" is a string of characters delimited by dots (.).

Example Scenario

Let's consider an example where a RabbitMQ exchange is set up with a topic exchange type. Suppose three messages are published to the exchange with the following routing keys:

  1. asia.china.beijing
  2. asia.india.delhi
  3. europe.uk.london

And there are queues bound with the following binding keys:

  • Queue A: asia.*.*
  • Queue B: *.china.*
  • Queue C: europe.#

Message Delivery

  1. Message 1 with routing key asia.china.beijing:
    • Delivered to Queue A (matches asia.*.*)
    • Delivered to Queue B (matches *.china.*)
  2. Message 2 with routing key asia.india.delhi:
    • Delivered to Queue A (matches asia.*.*)
  3. Message 3 with routing key europe.uk.london:
    • Delivered to Queue C (matches europe.#)

Key Differences: Wildcard in Routing Key vs Binding Key

While both routing keys and binding keys can use wildcards, their purposes and use cases differ:

  • Routing Key Wildcards: Typically not used by the producers. The routing key is generally a clear, precise identifier made by the producer to direct the message explicitly.
  • Binding Key Wildcards: Used extensively in topics exchanges to allow different queues to subscribe to a pattern of messages. This flexibility lets consumers filter messages based on multiple criteria expressed in these patterns.

Practical Considerations

When designing messaging systems using RabbitMQ with topic exchanges, it is crucial to understand how the combination of routing and binding keys work together. Misconfigurations can lead to messages not being delivered as expected or overwhelming a queue with unwanted messages.

Summary Table

FeatureRouting KeyBinding Key
PurposeDirects the message to the appropriate queues based on content.Defines patterns to filter messages desired by a queue.
Wildcard UseGenerally not used with wildcards.Often uses wildcards to define broad or specific patterns.
Exampleslog.info, user.data.update*.info, user.#, log.*

Conclusion

Understanding the nuances between routing keys and binding keys in RabbitMQ, especially with wild cards in a topics exchange, is essential for effectively designing and operating a message-driven system. It balances flexibility in message routing with the specificity necessary to ensure messages reach their intended destinations efficiently and accurately.


Related reading
Course
Beginner
27 lessons
10 hours
System Design Fundamentals

Build a strong foundation in designing scalable, reliable distributed systems.

View the course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

System Design practice on Codemia

Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.

Practice system design

All Rights Reserved.