Quorum queues (recommended) in RabbitMQ - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Quorum Queue Replication

In RabbitMQ, what is the main difference between a quorum queue and a classic mirrored queue regarding message replication?

A Quorum queues replicate messages using the Raft consensus algorithm, ensuring strong consistency, while classic mirrored queues replicate asynchronously without consensus.

B Quorum queues replicate messages asynchronously without consensus, while classic mirrored queues use Raft for strong consistency.

C Neither quorum nor classic mirrored queues replicate messages; replication is handled by external plugins.

D Both quorum and classic mirrored queues use the Raft consensus algorithm for replication.

💡 Hint

Think about how quorum queues ensure data safety and consistency.

Quorum queues use the Raft consensus algorithm to replicate messages synchronously across nodes, providing strong consistency and fault tolerance. Classic mirrored queues replicate asynchronously, which can lead to inconsistencies during failover.

💻 Command Output

intermediate

Queue Declaration Output

What is the output of the following RabbitMQ CLI command when declaring a quorum queue named 'task_queue'? rabbitmqctl add_queue --quorum task_queue

RabbitMQ

rabbitmqctl add_queue --quorum task_queue

A Error: unknown command 'add_queue'

B Queue 'task_queue' declared as quorum queue

C Queue 'task_queue' declared as classic mirrored queue

D Command executed successfully with no output

💡 Hint

Check the correct RabbitMQ CLI command for declaring queues.

The command 'rabbitmqctl add_queue' does not exist. Queue declaration is done via AMQP clients or rabbitmqadmin, not rabbitmqctl.

❓ Configuration

advanced

Configuring a Quorum Queue Policy

Which of the following JSON policy definitions correctly sets all queues with names starting with 'q_' to be quorum queues in RabbitMQ?

A {"pattern":"q_*","definition":{"queue-type":"classic"},"priority":0,"apply-to":"queues"}

B {"pattern":"^q_","definition":{"ha-mode":"all"},"priority":0,"apply-to":"queues"}

C {"pattern":"^q_","definition":{"queue-type":"quorum"},"priority":0,"apply-to":"queues"}

D {"pattern":"^q_","definition":{"queue-type":"quorum"},"priority":10,"apply-to":"exchanges"}

💡 Hint

Look for the correct pattern, queue-type, and apply-to fields.

Policy A correctly uses a regex pattern starting with ^q_, sets queue-type to quorum, applies to queues, and has a valid priority.

Option C uses ha-mode which is for classic mirrored queues.

Option C uses a wildcard pattern incorrectly and sets queue-type to classic.

Option C applies to exchanges, not queues.

❓ Troubleshoot

advanced

Diagnosing Quorum Queue Node Failure

A quorum queue with 3 nodes loses one node unexpectedly. What is the expected behavior of the queue after this failure?

A The quorum queue stops accepting messages until the failed node is restored.

B The quorum queue switches to classic mirrored mode automatically.

C The quorum queue loses all messages and deletes itself automatically.

D The quorum queue continues operating normally with the remaining 2 nodes, maintaining data availability.

💡 Hint

Consider how quorum queues handle node failures with Raft consensus.

Quorum queues require a majority of nodes (quorum) to operate. Losing one node out of three still leaves a majority, so the queue remains available.

✅ Best Practice

expert

Choosing Queue Type for High Availability

For a critical messaging system requiring strong consistency and automatic recovery from node failures, which queue type and configuration is the best practice in RabbitMQ?

A Use classic mirrored queues with ha-mode set to 'all' and manual failover.

B Use quorum queues with at least 3 nodes and enable automatic leader election.

C Use classic queues without mirroring and rely on client retries.

D Use quorum queues with a single node to reduce complexity.

💡 Hint

Think about consistency, fault tolerance, and automation.

Quorum queues with multiple nodes provide strong consistency via Raft, automatic leader election, and fault tolerance, making them ideal for critical systems.

Classic mirrored queues require manual failover and can have inconsistencies.

Single-node quorum queues lose fault tolerance benefits.