Future-proof queue configuration that favors availability

[ghost]

I would like to implement a queue behaviour that favors availability over consistency. In a three-node rabbitmq cluster (currently version 3.8.18) I would like to have a queue that is running on a single node but fails over to another one when the leader goes down. I don't care if I lose any or all messages in the process as long as the queue remains available.

Quorum queues do not seem to be the way to go since they explicitely favor consistency and do not guarantee availability. The behaviour could possibly be implemented by using a two-way mirrored classic queue with a ha shutdown policy of always but classic mirrored queues are to be removed in the future. Am I missing something or is there really no future-proof way to do this right now?

[mkuratczyk]

Can you explain the use case for such a queue? What would such a queue be used for?
In some cases, auto-delete and/or exclusive queues serve a similar purpose - they are there as long as they are needed and can be redeclared on another node if the node they were on goes down. They get deleted when there are no consumers so perhaps that's not what you want but on the other hand - if losing data is not a concern then why not just delete the queue if no-one's consuming the data.

[ghost]

It's a scenario in which the queue contains messages that are usually consumed instantly so it will never contain many messages and will be empty for most of the time. The data contained in the messages is not that important, it's basically measurement values coming in from another system in a way that newer values will invalidate previous ones and missing a few measurements is not a big issue however the system has to keep working even when a single rabbitmq node (or the kubernetes node executing the container) is shut down or experiences an outage.

The queue is to be declared by e.g. the kubernetes topology operator and the applications accessing the queue only use declarePassive so they are unable to redeclare the queue if it is deleted as it is the case for a non-mirrored queue which is not durable when the leader is restarted.

[ghost]

While writing that reply I realized that a non-mirrored, non-durable classic queue that is automatically recreated by the application would work for my use-case. The point my idea went off track was when I wanted to take the queue declaration out of the application. Unless there's a better way, I'm pursuing this path for now. Thanks a lot for your answer.