RabbitMQ - Use case for non-durable queues

Question

I don't really get the use case of non-durable queues. So I have a service that should run permanently and that consumes messages of RabbitMQ. I don't care if some messages are getting lost. As far as I understood, non-durable queues won't be recreated if the RabbitMQ server is restarted. So for example if my service has a non-durable queue and RabbitMQ crashes and is getting restarted, my service would only throw exceptions since the queue is not available anymore, right?

So the only use case I can imagine for non-durable queues is for testing services because in that case you don't care about deleted queues or messages.

Answer 1

As you stated correctly "non-durable queues won't be recreated if the RabbitMQ server is restarted" which also means that there will be loss of messages in this case.

In essence as @vvv444 notes, durable queues are also known as Transient queues -- this hints to it's usage.

Transient Data: Non-durable queues are a good fit for transient data that does not need to be stored long-term. This could include real-time analytics or metrics, which are important in the moment but may not be needed after a certain point.

High-throughput, low-value data: In cases where the sheer volume of data being processed makes persistence impractical or undesirable, non-durable queues can be a good fit. If you're processing millions of messages per minute and the individual value of each message is low, then the cost (both in terms of resources and complexity) of ensuring that every single one of those messages is durable might outweigh the benefits.

Testing: As you mentioned, non-durable queues can be useful for testing, as they allow for easily cleanable setups and may improve performance due to not having to write messages to disk.

Re "if my service has a non-durable queue and RabbitMQ crashes and is getting restarted, my service would only throw exceptions" You're correct that if RabbitMQ crashes and is restarted, non-durable queues and the messages within them will be lost. However, if the services that produce and consume from these queues are designed with this in mind, they can handle this scenario gracefully. A common pattern for RabbitMQ integration is to build services in a way that they control the entire lifecycle of a queue. This includes creation, binding, and deletion.