Learn RabbitMQ - Queue Features & Configuration

#Introduction

So far we've declared queues with queue_declare without thinking too much — yet a single parameter changes the entire character of a queue. In modern RabbitMQ, the choice of queue type is the most important architectural decision after choosing the broker: classic, quorum, and stream have different reliability, performance, and feature trade-offs.

This episode also introduces queue arguments — declaration parameters that control queue behavior in detail, from queue length limits and TTL to behavior when the queue is full. These arguments are what allow a queue to protect itself from message bursts.

Finally, we discuss declaration modes: durable, exclusive, auto-delete, and passive. Wrong declarations are the most common source of errors in RabbitMQ — for example, re-declaring a queue with different arguments in the same environment.

#Queue Types

#Classic Queues (v1 and v2)

A classic queue is the default type since RabbitMQ's early days. It is the most flexible in features (priority, lazy mode) and fast for simple scenarios. Starting with RabbitMQ 3.10, there are two storage versions: the old classic v1 and the more efficient classic v2. For simple single-node setups, a classic queue remains a valid choice.

The classic queue's weakness: it is not suitable for high availability. If a node dies, the queue is lost — unless mirrored with the old, no longer recommended pattern. For HA, use quorum.

#Quorum Queues

A quorum queue (3.8+) is based on the Raft consensus algorithm: messages are replicated across several nodes and guaranteed not to be lost as long as a majority of nodes are alive. This is the recommended queue type for production and high availability. Full details are in episode 20.

#Stream Queues and Priority Queues

A stream queue (3.9+) stores messages as an append-only log and allows re-consumption from any offset — details in episode 21. Meanwhile, a priority queue orders message delivery based on the priority value:

rabbitmqadmin declare queue name=tasks arguments='{"x-max-priority":10}'

x-max-priority defines the priority range (0-255). The higher the value, the higher the priority for the message to leave the queue.

#Queue Properties and Arguments

#Length Limits and Overflow

x-max-length limits the number of messages, x-max-length-bytes limits the total size. When the limit is reached, behavior is governed by x-overflow:

• drop-head (default) — the oldest message is discarded.
• reject-publish — publishing is rejected and the publisher receives a Basic.Nack.

rabbitmqadmin declare queue name=log_buffer \
  arguments='{"x-max-length":10000,"x-overflow":"reject-publish"}'

#TTL and Expiration

• x-message-ttl — the maximum age of each message in milliseconds.
• x-expires — the queue's own lifetime if there are no consumers.

rabbitmqadmin declare queue name=notif_ephemeral \
  arguments='{"x-message-ttl":30000,"x-expires":300000}'

Messages in notif_ephemeral expire after 30 seconds, and the queue is deleted automatically if unused for 5 minutes.

#Queue Declaration

Four declaration modes you must understand:

• durable=True — the queue survives a broker restart.
• exclusive=True — the queue is for a single connection; deleted when the connection closes.
• auto_delete=True — the queue is deleted when the last consumer stops.
• Passive declare — only checks whether the queue exists, without creating it.

Passive declaration

import pika.exceptions
 
channel = connection.channel()
try:
    channel.queue_declare(queue="cek", passive=True)
    print("queue cek ada")
except pika.exceptions.ChannelClosedByBroker:
    print("queue cek tidak ada")

The queue_declare(passive=True) call is very useful for health checks: if the queue doesn't exist, the channel is closed with a 404 error.

#When to Use a Given Queue Type

A guide to choosing queue types:

• Single node, data can be lost: classic queue.
• Need HA and message accuracy: quorum queue.
• Need replay and high throughput: stream queue.
• Need priority-based ordering: priority queue (classic).
• Temporary log buffer: classic with x-max-length and x-overflow.

#Conclusion

In episode 10 you compared classic, quorum, stream, and priority queues; mastered arguments like max length, TTL, expiration, and overflow behavior; and understood the durable, exclusive, auto-delete, and passive declaration modes.

Key takeaways:

• Classic queues are fast but not HA; quorum queues are for safe production use.
• Stream queues store a log that can be replayed; priority queues order messages.
• x-max-length and x-overflow limit queue growth.
• x-message-ttl limits message age; x-expires limits queue lifetime.
• Exclusive queues are deleted automatically when the connection closes.
• Passive declare is useful for checking whether a queue exists.
• Queue arguments must not change in the same environment.

In the next episode we will build dead letter exchanges — a rescue path for messages that fail to process, dumping them into a dedicated queue with x-death headers, applying retry and parking lot patterns, and monitoring the flow of rejected messages. This is the most important mechanism for building a resilient messaging system!