RabbitMQ / Basic: protocol resources, routing and ownership / Lesson 2

Exchanges, queues, bindings and routing

Design routing rules from subscriber requirements and distinguish an exchange name from a queue destination.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Compare direct, fanout and topic exchange semantics.
Explain default-exchange routing and topology ownership.

An exchange applies bindings

A publisher sends to an exchange with a routing key; the exchange type and bindings determine destination queues. The routing key is not automatically a queue name except under specific conventions such as the default exchange. A direct exchange matches exact binding keys, a fanout exchange ignores the key and routes to bound destinations, and a topic exchange matches dot-separated patterns. Choose from actual subscriber needs. A queue per worker instance creates a different delivery relationship from several workers sharing one service queue, even when all queues have similar names in the interface.

Topic wildcards match words, not arbitrary substrings

In a topic binding, star matches exactly one dot-separated word and hash matches zero or more words. The key parcel.accepted therefore matches parcel.star conceptually when star is the actual wildcard character, but a three-word key needs a matching three-word pattern or hash. Avoid confusing this grammar with filesystem globs or regular expressions. The JSON example uses parcel.* for two-word parcel events and audit.# for an expandable audit family. A broad hash binding can deliver much more traffic than expected, so review its subscriber purpose and data-disclosure boundary before choosing it for convenience.

json Synthetic topic-routing design

{"exchange":"lab.events","type":"topic","bindings":[{"queue":"lab.parcel-view","routing_key":"parcel.*"},{"queue":"lab.audit-view","routing_key":"audit.#"}]}

The patterns use AMQP topic word matching; this is not a complete definitions-import document.

The default exchange has special routing

The default exchange exists with an empty publishing name. Declaring a queue creates its automatic binding using the queue name as routing key, which makes direct-to-queue-looking publishing possible while an exchange still participates. It is not the same thing as an application exchange named default, and amq.default is not its publishing name. Use a separately named direct exchange for ordinary custom bindings rather than treating this special exchange as a normal configurable routing table. A missing application exchange can close the channel; a real exchange with no matching binding is a different unroutable-message case.

Predict direct routing from supplied bindings

The offline dictionary maps two exact keys to destination lists. A parcel.accepted publication selects labels, while parcel.unknown selects no destination. This model does not implement exchange-to-exchange routing, alternate exchanges or broker permissions; it checks the stated direct-routing rule only. In a real topology, several queues can share a binding key and each receive a copy. Keep topology ownership explicit so one application does not silently change another subscriber's contract. Declare stable durable resources consistently and review property-equivalence errors rather than deleting an existing queue simply to make a declaration succeed.

python Offline direct-routing lookup

bindings = {'parcel.accepted': ['labels'], 'parcel.sorted': ['sorting-audit']}
assert bindings.get('parcel.accepted', []) == ['labels']
assert bindings.get('parcel.unknown', []) == []
print(bindings.get('parcel.accepted', []))

Expected output

['labels']

Only the supplied exact key selects labels; no RabbitMQ exchange is contacted.

Verify intended delivery and intended absence

A useful routing review lists sample keys, expected subscriber queues and keys that must not reach each subscriber. Include a missing-binding case and an unexpected extra binding, because accidental fanout can duplicate business effects or expose data to an unrelated service. Binding availability and consumer availability are separate: a message can route to a queue without an active worker. This course imports no definitions and declares no topology. Its JSON is a design fixture, and its local lookup demonstrates exact matching without claiming the broker validated bindings or delivered any message.

Common errors and fixes

A routing key is assumed to name a queue on every exchange.

Why it happens: Default-exchange behavior was generalized to custom exchanges.
How to fix it: Inspect the selected exchange type and actual bindings.
Prevent it next time: Document exchange and queue identities separately.

parcel.* unexpectedly misses a three-word event key.

Why it happens: Star was interpreted as an arbitrary-length substring.
How to fix it: Use the documented one-word or zero-or-more-word pattern deliberately.
Prevent it next time: Keep positive and negative key fixtures in routing reviews.

A service receives copies intended for another subscriber.

Why it happens: A broad or extra binding changed the routing contract.
How to fix it: Review binding ownership and narrow the approved subscription.
Prevent it next time: Verify both expected delivery and expected nondelivery.

Check your understanding

1. Does a queue with no active consumer prevent an exchange from routing to it?

Show worked solution

Not inherently. Routing depends on the exchange and bindings, while consumption depends on subscribers and capacity. A correctly routed message can wait in the destination queue. Diagnose topology, stored backlog and worker progress separately rather than changing a binding because no business result appeared immediately.

2. Why is testing only one successful key insufficient for a topic subscription?