Is it a bad design to have 50K bindings on a single RabbitMQ queue?

Is it a bad design to have 50K bindings on a single RabbitMQ queue?

We are designing a new feature in our system where consumers (consumer == internal application) need to receive messages about changes in items they are interested in.
From the statistics we gathered we see the maximal number of items a single consumer can be interested in is 50K (on average it would be ~15K).
Initial tests shows that this is works OK and RabbitMQ handles it, but when we delete such a queue (if for example we scaling down the system and shutting down one of the instances) it takes a few minutes for it to be deleted and the RabbitMQ management portal becomes unresponsive.

Does it make sense to have so many bindings or is it a bad design?

  • We we’ll have around 50 instances of the consumers, each one with its own queue which is not persistent and should be auto deleted when the consumer shut down

Go to Source
Author: Tamir Dresher