RabbitMQ topology to route a dynamic set of message categories to a static set of consumers each with their own queue

What I'm trying to do: multiple producers push data in dynamic categories into a Named exchange. Multiple consumers need to pick up this data from these dynamically named queues and act on them.

The problem is that all of the examples of consumption that I see require the consumer/subscription to have a specific queue name, and my consumers don't know the names of the queues, nor do they need to know this.

Why am I doing this? two reasons:

1. I can have N of these dynamic categories at a time. I'd like the queue to serve these categories equally. currently we have one queue which accepts all of these categories and serves them in FIFO (which means that some categories are starved for some time).

2. Being able to serve all categories equally, rather than fifo, lets me come up with interesting QoS (by default I understand that Rabbit will round-robin serve messages).

so, back to my question (if its valid): is it possible to consume messages from a queue?

If having dynamic subscribers is an option, I'd like to suggest two possible solutions:

Solution 1:

• Use a topic exchange.
• Use the mandatory delivery flag when publishing messages to your exchange.
• If a message is rejected: create a queue, bind it for the particular routing key and start a subscriber on the queue, the re-publish the rejected message.
• Use auto-deleting queues so when subscriber stops, their queues will disappear and the whole process of auto-creation can restart.

Solution 2:

• Use a topic exchange.
• Use the immediate delivery flag when publishing messages to your exchange.
• If a message is rejected: create a queue, bind it for the particular routing key and start a subscriber on the queue, the re-publish the rejected message.
• Use persistent queues. Since queue creation is idempotent, it's OK to go through the re-creation procedure, the essential part here is ensuring a live subscriber is listening on the queue.

If dynamic subscribers are not an option, then here is what I propose. Assuming you're limited to n subscribers:

• Define a strategy that hashes the dynamic categories in n routing keys,
• Use a direct exchange,
• Bind n queues on it for the n routing keys,
• Have one subscriber per queue.