title: In RabbitMQ which is more expensive, multiple queues per exchange, or multiple exchanges and less queues per each?
body: <p>So we decided to go with RabbitMQ as a message/event bus in our migration to micro-services architecture, but we couldn't find a definite answer on what is the best way of putting our queues, we have two options to go with:</p>
  
  <ol>
  <li><p>One main exchange which will be a Fanout exchange, which in turn will fan messages out to a main queue for logging and other purposes and another sub exchange which will be a topic exchange and route the messages to each desired queue using the message routing key. We expect the number of queues behind the sub-exchange to be some how a large number. This can be explained by this graph:
  <a href="https://i.stack.imgur.com/0EpJJ.png" rel="noreferrer"><img src="https://i.stack.imgur.com/0EpJJ.png" alt="First Option"></a></p></li>
  <li><p>One main exchange, which will be a Topic exchange, with still one main queue bound to that exchange using "#" routing key. That main exchange will also handles main routing to other sub exchanges, so routing keys might be "agreements.#", "assignments.#", "messages.#", which are then used to bind multiple topic sub-exchanges, each will handle sub routing, so one sub exchange might be handling all "assignments" and queues bound to that exchange could be bound by routing keys like "assignments.accepted", "assignments.deleted"...In this scenario, we feel like the huge number of queues will be less per exchange, they will be somehow distributed between exchanges.
  <a href="https://i.stack.imgur.com/Ambt1.png" rel="noreferrer"><img src="https://i.stack.imgur.com/Ambt1.png" alt="enter image description here"></a>
  So, which of these scenarios could be the best approach? Faster on RabbitMQ, less overhead.</p></li>
  </ol>
  
  <p>Taking in mind, all queues, exchanges and bindings will be done on the fly from the service which will be either publishing or subscribing.</p>