We've got an application which will be using RabbitMQ and have several different queues for passing messages between tiers.
Initially, I was planning to use multiple direct exchanges, with one for each message type, but it looks like having a single topic exchange with queues using different routing key bindings will achieve the same thing.
Having a single exchange also seems like it would be a bit easier to maintain, but I was wondering if there is any benefit (if any) of doing it one way over the other?
Option 1, using multiple direct exchanges:
ExchangeA (type: direct)
-QueueA
ExchangeB (type: direct)
-QueueB
ExchangeC (type: direct)
-QueueC
Option 2, using single topic exchange:
Exchange (type: topic)
-QueueA (receives messages from exchange with routing key of "TypeA")
-QueueB (receives messages from exchange with routing key of "TypeB")
-QueueC (receives messages from exchange with routing key of "TypeC")
Assuming both models are being considered to be implemented using one broker running, there's little difference that I can see.
Option 2 seems more common in the real world for solving this kind of routing problem (at least in my anecdotal experience) and it's exactly the challenge that Topic Exchanges exist to solve.
The only difference that you might encounter would relate to routing speed. I don't know for sure if Exchange routing (based always on an exact string match) is faster in RabbitMQ when compared to the routing key technique used in Topic Exchanges (which can include wildcards like #
and *
). My hunch would be that Exchange discrimination would be faster, but you could experiment for yourself to find out, or try contacting the RabbitMQ team to ask them.
Finally, if you go with option 1 end up with lots of queues then you'll have a proportional proliferation of Exchanges. That sounds like a maintenance headache. If you'll only have a handful of queues then it won't be too much of an issue.