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 di
For a single small node with little load there is little difference. Most people go with option two for said reasons above.
When designing the system you should ask your self how might this expand in the future.
How is it going to scale ?
Do I need it to scale ?
Do I want to add a high a availability cluster in the future ?
Is my routing going to change...
Option 2 provides a lot more flexibility in most cases.
It allows you to do things like attach a new consumer to the Exchange with its own queue and capture any subset or all of your message flow easily. ( these queues could be on other nodes in a cluster or mirrored to n nodes providing failover) A typical use case would be logging all messages using a 4th queue.
If your bottleneck is on the processing side, You can also further subdivide your message topics and perform some amount of prioritization with out having to change your publishers. Example: ToppicA.urgent, processed by dedicated consumer, TopicA.log eventually processed.
The short answer is go with option 2 unless you have very specific performance requirements, If for example you need to process say a sustained rate of more than 50k msg/s you might want to think about option 1 on dedicated nodes, but for normal flows option 2 will be easier to scale and maintain.