CODEWITHSUNDEEP
rabbitmqmessage-queue
user2957954
user2957954

Reputation: 1249

Multi-topic message queue(s)

I have a rather theoretical question about the architecture of microservices.

Assume that we have two microservices A and B that interact with each other through RabbitMQ. When A has a question it sends a message to a queue_1 and receives an answer from B through a queue_2 (the communication can thus stay asynchronous).

            ------------
       --->   queue_1    --->
   A        ------------      B
            ------------
      <---   queue_2     <---
            ------------

Now I understand that we will have at least 4 different kinds of questions that could be asked by A. My question is what is the best way to configure that?

Is it ok to create a separate queue pair for each kind of question (so they are not mixed and it's simpler to determine, what kind of answer to expect)?

Or is it considered to be not very optimal and it's better to create a single channel for all the messages and to route them inside the microservices?

I would be thankful for any kind of links and information on this topic.

Upvotes: 2

Views: 1120

Answers (1)

M.A. Hanin
M.A. Hanin

Reputation: 8084

There is no simple answer; it is the architect's job to thoroughly analyze the real scenario and determine the proper structure.

Lets say the request types are W,X,Y and Z. For simplicity, lets assume a single consumer per queue. If W and X are quick to process, while Y and Z are lengthy operations, then having everything in a single queue means that once you have a Y or Z at the top of the queue then any queued W and X will spend a lot of time enqueued, waiting for the consumer to finish running the lengthy process. In this case, it could be better to have one queue for Ws and Xs and another for Ys and Zs.

Think about a real-life queued service, lets say a supermarket. You have your normal lanes to the cashiers, and you have those "up to 10 products" fast lanes.

Another thing to consider is: do you want different policies and guarantees applied to each request type? For example, it might be that Ws are "document messages" which arrive every once in a while, that you must not lose (need to be persisted to disk), and must be processed regardless of when they were dispatched (no "time-to-live"), while Xs are "event messages" that arrive all the time, must be processed quickly, and are only significant for a few seconds (have short TTL). This means that they need different queues.

Maybe Ys and Zs have different priorities: maybe you must process Zs ASAP, even if there are pending Ys. This would again call for different queues.

If all request kinds are equal in their importance and such, then perhaps a single queue would be better for the sake of simplicity.

The same discussion goes for the response queues. You could have four different request queues and a single response queue. Or four response queues, or two... (it doesn't have to be symmetric).

There are other issues to consider, such as security, scalability and performance.

The actual routing is no real challenge, and determining which handler should handle each message type could be easily aided by using message headers (you don't have to inspect the actual message body to determine its type), which is really just as simple as having different queues.

Upvotes: 2

Related Questions