🚦 RabbitMQ Priority Queues That Actually Prioritize With AI

We shipped a priority queue, watched urgent messages get processed in perfect order in the demo, and then discovered in production that urgent messages routinely waited behind a wall of normal ones. Nothing was misconfigured in the obvious sense. The x-max-priority was set, the publishers tagged urgent messages correctly, and the priority queue was doing exactly what it promised — ordering the messages still sitting in the queue. The problem was the consumer’s prefetch. It had already pulled a batch of normal-priority messages into its local buffer, and the queue can’t reach into a consumer’s buffer to reorder. That’s the trap, and it’s the whole reason priority queues quietly disappoint people.

This is a small enough feature that AI can design the whole thing in one shot — and a subtle enough one that its one-shot answer is usually wrong in the same way mine was. The model will declare the queue and forget that prefetch defeats it. So the value of working with AI here isn’t the config; it’s making the model surface the interaction that bites under load.

Ask about prefetch in the same breath as priority

If you ask “how do I make a priority queue,” you’ll get a correct declare statement and a broken design. Ask about the consumer behavior too.

I want a RabbitMQ priority queue with two tiers, urgent and normal, where urgent messages are always processed first. My consumers currently use a prefetch of 50. Will urgent messages actually jump ahead of normal ones with that prefetch? Explain the interaction between priority and prefetch, and tell me the prefetch I should use.

The answer you need explains that a prefetch of 50 buffers up to 50 normal messages locally, so an urgent message that arrives after them waits behind them — priority is honored at delivery, and delivery already happened. The fix is a very low prefetch, often 1, so the consumer asks for the next message only when it’s ready and the queue can hand it the highest-priority one available.

Declare it right, the first time

x-max-priority must be set when the queue is declared. You cannot add it later, and redeclaring with a different value fails — so decide the level count up front. A small number is almost always enough; each level carries overhead and nobody needs ten.

rabbitmqadmin declare queue name=work-priority \
  arguments='{"x-max-priority": 3}'

Publishers set the priority per message:

channel.basic_publish(
    exchange="",
    routing_key="work-priority",
    body=payload,
    properties=pika.BasicProperties(priority=2),  # higher = sooner
)

And the consumer that makes priority real uses a low prefetch:

channel.basic_qos(prefetch_count=1)  # so priority is honored at delivery

Don’t forget starvation

A priority queue with a steady flood of urgent messages will starve the normal tier forever — there’s no built-in aging. If “low priority must eventually run” is a real requirement, a single priority queue may be the wrong shape, and two plain queues with weighted consumers (most consumers on urgent, a guaranteed few on normal) can give you both responsiveness and a floor for the low tier. Ask the AI to compare the two designs for your specific traffic mix rather than assuming the priority queue is automatically right.

My traffic is roughly 5% urgent and 95% normal, and normal messages must still get processed within a few minutes even during an urgent spike. Compare a single priority queue against two separate queues with weighted consumers for this mix, and recommend one.

Where AI gets priority queues wrong

The dominant failure is the one that started this piece: the model declares the priority queue and never mentions that a high prefetch silently defeats it. It’s such a clean-looking design that nothing flags the problem until production load arrives. I always close the loop with a direct question: “With my consumers’ current prefetch, will priority actually take effect?” If the answer doesn’t immediately connect prefetch to priority, the design is broken.

The second overreach is over-leveling. Ask for priorities and AI will sometimes propose five or ten tiers because more sounds more flexible. Each level adds overhead, and real workloads collapse to two or three meaningful tiers. And the model rarely volunteers the starvation problem unless you raise the “low priority must still run” requirement explicitly.

My loop for priority queues

I make the AI design the queue and the consumer prefetch together, refuse any design with a high prefetch, and keep the level count small. Then I load-test on staging with a realistic traffic mix and the production prefetch — because the prefetch trap only reveals itself under load, never in a quick functional check. I confirm urgent messages are processed ahead of normal ones and that the normal tier isn’t starving. The AI drafts the design; the staging load test is the only thing that proves priority actually preempts.

The prefetch side of this connects directly to the consumer prefetch and QoS tuning guide, and the broader RabbitMQ category covers the routing decisions that feed a priority queue. The design prompts I run this with live with my other prompts.