I am thinking about the RabbitMQ topology for my new API. Each API
call has an API key, and can be one of three calls. I'll have the
three controllers parse / validate the arguments, and then enqueue the
tasks in RabbitMQ. I will then have a service that consumes this
queue(s), and process each of the tasks.

Each API calls will take different times to process.

The question is, should I have

1. One queue where all API calls are fed into (1 queue)
2. One queue per API call (3 queues)
3. One queue per API key (N queueswhere N is the number of customers)
4. One queue per APi key / API operations (3*N queues)

Is there a performance advantage to dequeuing from multiple queues
versus just one? I know that each queue has around 4kb of extra
information with it, so we don't want to make too many. Is there any
sort of locking disadvantage to just having one queue with a lot of

Thanks for your help!

Search Discussions

Discussion Posts

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 1 of 2 | next ›
Discussion Overview
grouprabbitmq-discuss @
postedOct 27, '11 at 4:40a
activeOct 27, '11 at 10:36a



site design / logo © 2022 Grokbase