What is the best queue type for RPC calls?

[safe-bug]

Hello

We offer several services that receive client requests via a REST API. These services make an RPC call through RabbitMQ to another service, and the response time must be prompt.

However, if we use Quorum or mirrored queues, all messages will be persisted, creating high I/O operations on the disks. This persistence is unnecessary because if the client request is not answered promptly, it will time out, and message recovery is not needed.

Using transient queues is an option, but if the host node fails, the queue definition will not survive and also other nodes doesn't have the queue definition, leading to disastrous consequences.

I'm now wondering what kind of queue to use for this use case. Is using RabbitMQ a bad practice, should I switch to other solutions like gRPC?

Thank you.

[michaelklishin]

Classic mirrored queues are deprecated and will be removed in 4.0.

You are likely overestimating how many disk I/O operations your disks can do. Higher disk I/O of quorum queues or classic queues v2 should not matter much for response queues.

What is important is whether those queues are very short-lived or long-lived. Very short-lived quorum queues do not make much sense, and their setup (given that they require 3+ replicas) will take dozens or hundreds time longer than the disk I/O parts.

So for response queues, a non-replicated classic queue v2 makes more sense, whether they are short-lived or long-lived. But if data safety is more important than response latency and response queues are long-lived (and therefore use known stable names and not server-generated unique ones), quorum queues should be used.

Streams do not really fit the request-response model and would not offer any benefits over quorum queues in this particular case, at least the way most users do it with RabbitMQ.

[safe-bug]

Thank you for your response, @michaelklishin.

I am currently using Spring AMQP and it handles the callback queues (specifically non-replicated exclusive classic queues) which are working fine. However, I am not sure what to choose for the consumer queue. This is a single, long-lived queue where several consumers are connected, and data safety is not a concern for its messages.

If I choose transient queues, it may not be able to handle host failures. On the other hand, if I choose Quorum queues, there may be too many unnecessary processes happening - 1-replication, which is not needed since the messages will expire soon, and 2-persistence, which is unnecessary since data safety is not important. Something like to persist the queue metadata on every cluster node with transient messages in it (with no replication). Or still you suggest Quorom queues?

[michaelklishin]

If you are certain that data safety is not a concern, a non-replicated classic queue v2 would be my recommendation (as a rule of thumb). If you would like some extra data safety, move it to be a quorum queue.

Transient entities will no longer be supported in RabbitMQ 4.0+. They don't offer much in terms of latency reduction anyway because what is transient in their case is the record of the queue itself in the metadata store. CQv2 in the upcoming 3.12.0, for example, always persist messages to disk to reduce memory footprint.

[safe-bug]

But, if the host rabbit node goes down, there will be a service downtime. The discussion that @mkuratczyk mentioned (#6376) is the exact use case I'm looking for

[safe-bug]

Is it possible to disable the message persistence that will be implemented in version 3.12.0 for CQv2?

[mkuratczyk]

There's one situation where they may not be persistent. You can see the docs for 3.12 here: https://next.rabbitmq.com/classic-queues.html#persistence

Having said that, rather than making assumptions performance, we'd highly appreciate if you could test 3.12 and see if the performance it provides, satisfies your requirements.

[mkuratczyk]

I think this is a relevant discussion/idea #6376. Please add your comments there: what are the important requirements for you, what is less/not important, what kind of throughput you'd expect to be handled and any other comments you have related to the ideas described.

[safe-bug]

Thanks Michal, this is the exact use case I was looking for