3

The problem to solve: Prevent a customer from starving other customers.

I plan for every customer to have their own queue and then one Consumer consuming from all those queues. In my case there could be hundreds of customers, but queues are cheap. Having a reasonable low prefetch count the default broker behavior (to randomly select which queue to pop from) should yield a satisfying result.

enter image description here

The issue with this strategy is when a new customer comes along. I can lazily create the queue and bind it to the exchange msg.in in the Publisher. But how do I get the Consumer to consume from this new customer.xxx queue?

It's almost the Topics pattern, but not really since I need a buffer per client. Nor can this be solved with Priority which will screw up the per customer message order. Is there a way to consume based on a pattern? Like there is for binding, eg. customer.*.

Polling the management API is an option, but will delay the processing of the first message of a new customer until the Consumer have polled. Having a separate pub/sub channel for meta-data like new customer.003 that the Consumer could act upon would reduce the latency (and avoid polling the API), but will make the Publisher more complex.

I've a feeling there's a nice solution out there, I just haven't been able to find it yet. Thankful for your feedback!

MyGGaN
  • 1,670
  • 3
  • 30
  • 40
  • Is there a reason to have all these separate queues that are being consumed from instead of just one that all the clients publish to? – mbrig May 02 '18 at 22:19
  • I've edited the question to rename client to customer to clarify. Thanks – MyGGaN May 02 '18 at 22:57
  • Can you clarify the sentence `... when a new customer comes along. I can lazily create the queue and bind it ...`. Could you, at the same time, notify the consumer a new queue has been created? – noxdafox May 03 '18 at 08:49
  • The queue creation and binding is idempotent so a publisher could always make sure the queue exists by simply create it every time. Performance wise this is not optimal, but that's what I meant. A better solution might be to publish with the mandatory flag set and, in case the was no customer queue bound, create it and also send a notification on the pub/sub meta channel I elaborated a bit on. – MyGGaN May 03 '18 at 12:26
  • Almost 3 years later, have you found a good solution to this? – Mircea-Andrei Albu Feb 18 '21 at 16:39
  • I have not, but it's still relevant. One alternative might be to have a priority queue combined with some throttling aware publishers that changes a customers priority depending on e.g. messages/s. – MyGGaN Mar 02 '21 at 11:41

0 Answers0