Queue Properties

Declaring a queue is a decision

Every time you declare a queue you pass a handful of flags. They look like boilerplate, but each one changes how long the queue lives and who can use it. Get them wrong and your queue either vanishes when you didn’t expect it to, or lingers forever when you wanted it gone.

There are three boolean flags and one bag of extra arguments.

durable — survive a broker restart

A durable queue is written to disk, so its definition survives a RabbitMQ restart. A non-durable (transient) queue is forgotten when the broker restarts.

This is the flag people most often get wrong, so be precise: durable preserves the queue itself, not the messages in it. To keep the messages too, they must also be published as persistent (next lesson). Durable queue + persistent messages is the combination for “survives a restart” — one without the other still loses data.

For any queue that matters, set durable: true.

exclusive — one connection only, then gone

An exclusive queue can only be used by the connection that declared it, and it is deleted automatically when that connection closes. It’s perfect for a temporary, private reply queue (you’ll see this in the RPC lesson), and wrong for anything shared.

auto-delete — gone when the last consumer leaves

An auto-delete queue is deleted once its last consumer unsubscribes (it must have had at least one). Useful for transient subscriptions where the queue has no reason to exist after the subscriber goes away.

Declaring a durable queue

Node

// durable: true → the queue definition survives a broker restart
await channel.assertQueue('orders', {
  durable: true,
  exclusive: false,
  autoDelete: false,
});

Python

# durable=True → the queue definition survives a broker restart
channel.queue_declare(
    queue="orders",
    durable=True,
    exclusive=False,
    auto_delete=False,
)

Go

// args: name, durable, autoDelete, exclusive, noWait, table
q, err := ch.QueueDeclare(
    "orders", // name
    true,     // durable
    false,    // auto-delete
    false,    // exclusive
    false,    // no-wait
    nil,      // arguments
)

x-* arguments — everything else

Beyond the three booleans, queues take an arguments table (often called x-arguments because the keys start with x-). These unlock the more advanced behaviour covered later in this course:

Argument	What it does
x-message-ttl	Messages expire after N milliseconds
x-expires	The queue itself is deleted after being unused for N ms
x-max-length	Cap the number of messages; overflow is dropped or rejected
x-dead-letter-exchange	Where expired/rejected messages go (the DLX lesson)
x-queue-type	classic or quorum (the clustering lesson)

🐇 The one-line takeaway

Declaring a queue sets its lifecycle: durable keeps the queue definition across a restart (but not its messages — those need to be persistent too), exclusive ties it to one connection and deletes it on disconnect, and auto-delete removes it when the last consumer leaves. Everything advanced — TTL, length limits, dead-lettering, quorum queues — is configured through the x-* arguments table.

What exactly does a durable queue preserve across a broker restart?

The queue definition and all its messages, automatically The queue definition — but messages survive only if they were published persistent Nothing; durable only affects performance Only the consumer subscriptions

When is an exclusive queue deleted?

After 30 seconds When the connection that declared it closes When the broker restarts Never — exclusive queues are permanent

An auto-delete queue is removed when:

Its last consumer unsubscribes It receives its first message The producer disconnects A message is acknowledged

Where do you configure things like message TTL, max length, and dead-lettering?

As boolean flags alongside durable In the queue's x-* arguments table On the connection string They cannot be configured per queue

Submit

Mark as complete