0

I'm looking to utilize the same queue for multiple subscriptions,

enter image description here

Just wondering if this a good practise, and what are pro's and con's of this design?

SanVEE
  • 2,009
  • 5
  • 34
  • 55
  • 1
    if messages are processed in the same way and state with topicID is not something you care about when processing that message in the queue then I see no problem in this approach. Though usually you have 1 publisher and 1 or many subscribers, that is the usual model but it does not mean you cannot do this. – Hassan Raza Sep 14 '20 at 08:50

1 Answers1

1

It depends on what do you do. There are a few use-cases for a centralized queue topology:

  1. Have a single source of messages for scale-out. Rather than having N number of subscription listeners and exhausting broker connections, you have only one queue to listen to and scale-out on.
  2. Centralized dead-letter queue - instead of handling dead-letter queue per subscription, you consolidate all dead-lettered messages in a single queue to consume from. Those messages will have information about their original source if that's needed for decision making.
  3. Migration scenario - when your old topic/subscription needs to be drained off the messages before it can be decommissioned.
Sean Feldman
  • 23,443
  • 7
  • 55
  • 80