Priorities, Delays, Length Limits and Single Active Consumer

Useful features, used carefully

Priority queues let urgent messages overtake others: classic queues support up to 255 levels through x-max-priority (use a small number such as 5), and quorum queues in 4.x support a simplified two-level priority (normal and high). Priorities only help when there is a backlog. Delayed delivery can be built with TTL plus dead-lettering (see the retry pattern) or with the delayed message exchange plugin; for long or high-volume delays, a scheduler or database is often better. Queue length limits (x-max-length, x-max-length-bytes) cap backlogs; the overflow behaviour decides whether to drop the oldest messages (drop-head, the default) or reject new publishes (reject-publish, which publishers see as nacks with confirms). Single active consumer (x-single-active-consumer) lets several consumers attach to a queue while only one receives messages at a time, with automatic failover: useful when strict ordering matters but you still want a standby. The consistent hash exchange plugin spreads messages over several queues by a hash of the routing key, keeping each key's messages in one queue.

Ordered processing with a standby consumer

Two instances attach; one is active and the other takes over if it dies.

channel.queue_declare(
    queue="ledger.entries",
    durable=True,
    arguments={
        "x-queue-type": "quorum",
        "x-single-active-consumer": True,       # strict order, automatic failover
        "x-max-length": 1_000_000,
        "x-overflow": "reject-publish",          # publishers get nacks instead of silent drops
    },
)

# both instances run the same code; RabbitMQ delivers to one at a time
channel.basic_qos(prefetch_count=1)
channel.basic_consume("ledger.entries", on_message_callback=apply_ledger_entry)

One cashier with a relief cashier waiting

Single active consumer is one cashier serving customers in strict order, with a relief cashier sitting behind who steps in the moment the first one leaves. Customers are never served by both at once.

त्वरित जाँच: What does the `reject-publish` overflow setting do when a queue reaches its length limit?

• Deletes the oldest messages silently
• Doubles the limit automatically
• Moves the queue to another node
• Rejects new publishes, which publishers see as nacks when confirms are enabled