RabbitMQ - Use case for non-durable queues

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.

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.

Transient (non-durable) queues provide some latency benefits in scenarios when queue lifetime is very short. For example, when a temporary queue is created per user connection to a web server. That's from the RabbitMQ documentation:

> Throughput and latency of a queue is not affected by whether a queue is durable or not in most cases. Only environments with very high queue or binding churn — that is, where queues are deleted and re-declared hundreds or more times a second — will see latency improvements for some operations, namely on bindings. The choice between durable and transient queues therefore comes down to the semantics of the use case.
>
> Temporary queues can be a reasonable choice for workloads with transient clients, for example, temporary WebSocket connections in user interfaces, mobile applications and devices that are expected to go offline or use switch identities. Such clients usually have inherently transient state that should be replaced when the client reconnects