🔀 Designing RabbitMQ Exchanges and Routing Keys With AI

The first RabbitMQ topology I ever inherited was a single direct exchange with forty routing keys hardcoded into a dozen services. Adding a new consumer meant editing every publisher, redeploying, and praying nobody fat-fingered a key. The broker worked fine; the design was the liability. RabbitMQ gives you exchanges, bindings, and routing keys as primitives, and it will happily let you build something unmaintainable with them.

Topology is also where I lean hardest on AI now. Not because it invents clever exchange types I’d never heard of, but because it’s a tireless rubber duck for “here’s what my services need to send and receive — what’s the cleanest binding layout?” The trick is treating its output as a draft topology you apply to a throwaway broker and probe, never something you rabbitmqadmin declare straight into prod.

Start by describing the message flows, not the exchanges

The mistake people make with AI here is asking “what exchange should I use?” That’s the wrong altitude. The model can’t answer well because it doesn’t know your flows. Instead, describe who publishes what and who needs to consume it, and let the routing fall out of that.

Here’s a prompt that gets me a usable starting point:

I run RabbitMQ for an order-processing system. Publishers: an orders service emits order.created, order.paid, order.shipped, order.cancelled. Consumers: a billing worker needs paid and cancelled events; a fulfillment worker needs paid and shipped; an analytics sink needs everything. Propose an exchange type and binding layout that lets me add consumers without touching publishers. Show the rabbitmqadmin commands to declare it, and explain why you chose that exchange type over the alternatives.

A topic exchange with routing keys like order.created, order.paid and consumers binding with patterns (order.* for analytics, order.paid/order.cancelled for billing) is the obvious answer here — but the value is the model laying out all the bindings consistently and explaining the trade-off against a direct exchange.

Make it produce declarative topology you can diff

I never accept a wall of imperative rabbitmqadmin calls without asking for the declarative version too. Ask the AI to emit the same topology as a definitions.json fragment or a Terraform rabbitmq provider block, because that’s what you’ll actually keep in version control.

# Apply the AI's draft to a STAGING broker only
rabbitmqadmin declare exchange name=orders type=topic durable=true

rabbitmqadmin declare queue name=billing durable=true
rabbitmqadmin declare queue name=fulfillment durable=true
rabbitmqadmin declare queue name=analytics durable=true

rabbitmqadmin declare binding source=orders destination=billing \
  routing_key="order.paid"
rabbitmqadmin declare binding source=orders destination=billing \
  routing_key="order.cancelled"
rabbitmqadmin declare binding source=orders destination=fulfillment \
  routing_key="order.paid"
rabbitmqadmin declare binding source=orders destination=fulfillment \
  routing_key="order.shipped"
rabbitmqadmin declare binding source=orders destination=analytics \
  routing_key="order.#"

Validate the routing before you trust it

This is the part AI cannot do for you, and it’s the whole point. A topology that looks right in a chat window can silently drop messages because a binding pattern is wrong or a queue isn’t bound at all. Publish synthetic messages and confirm each lands where it should.

# Publish a test event and watch where it routes
rabbitmqadmin publish exchange=orders routing_key="order.paid" \
  payload='{"id":"test-1"}'

# Confirm billing and fulfillment both got it, analytics too
rabbitmqadmin get queue=billing count=1
rabbitmqadmin get queue=fulfillment count=1
rabbitmqadmin get queue=analytics count=1

The smoke test I always run: publish a message with a routing key that nobody should match, and verify it goes nowhere. Unroutable messages are silent data loss unless you’ve set up an alternate exchange. Ask the AI about that explicitly:

For the topic exchange above, add an alternate exchange so unroutable messages are captured instead of dropped. Show the policy and the declaration.

rabbitmqadmin declare exchange name=orders-unrouted type=fanout durable=true
rabbitmqadmin declare queue name=unrouted durable=true
rabbitmqadmin declare binding source=orders-unrouted destination=unrouted
# Set alternate-exchange on the primary
rabbitmqctl set_policy AE "^orders$" \
  '{"alternate-exchange":"orders-unrouted"}' --apply-to exchanges

Where AI gets it wrong, and how to catch it

The model loves headers exchanges. They’re rarely the right call — they’re slower and harder to reason about than a well-chosen topic exchange, and most “I need headers” cases are really “I picked bad routing keys.” When AI reaches for a headers exchange, push back and ask it to re-derive a topic key scheme instead.

It will also occasionally bind a queue to a routing key that overlaps with another in a way that double-delivers. That’s why the synthetic publish test above matters: it surfaces fan-out you didn’t intend. I keep a small library of these validation prompts and snippets in my own prompts collection so I’m not rewriting them every time I stand up a new service.

The workflow that actually holds up

My loop looks like this: describe the flows to the AI, get a draft topology plus declarative config, apply it to a staging broker, publish synthetic messages across every routing key including the deliberately-unroutable ones, then diff the resulting message counts against what I expected. Only after that does the definitions.json go into the repo and onto production.

The AI compresses the tedious part — writing out twelve consistent bindings without a typo, remembering the alternate-exchange pattern, explaining why topic beats direct here. It does not replace the staging broker. A routing key is a contract, and contracts get tested, not assumed. For more on building reliable RabbitMQ systems, the rest of the RabbitMQ category digs into the patterns that sit on top of a clean topology.