AMQP · Study deck

AMQP Core Architecture: Exchange Types

AMQP routes messages like a sorting office.

Broker Bex is your guide for this deck.

archcorecomponents

Broker Bex, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Compare direct, fanout, topic, and headers exchanges for named routing needs.
Debug topic routing keys and queue bindings for industrial telemetry.
Explain: Different exchange types provide flexible routing patterns for various messaging scenarios.
Explain: Each bound queue receives its own copy, allowing independent consumers to progress at different rates.

Major section

Exchange Types

Different exchange types provide flexible routing patterns for various messaging scenarios.

Direct exchanges route messages based on exact routing key matches.
The application must choose a mandatory return, an alternate exchange, or discard; the exchange cannot infer the desired business response.
That distinction keeps broker receipt from being mistaken for successful routing.
Direct: Exact routing key match.

Direct exchange exact-match contract: a message with routing key error reaches every queue bound with error, does not reach queues bound with other keys, and a zero-match result must follow the declared mandatory-return, alternate-exchange, or discard policy. — A direct exchange copies a message only to queues with an equal binding key, while a declared policy handles zero matches.

Major section

Exchange Types (continued)

Each bound queue receives its own copy, allowing independent consumers to progress at different rates.

That broadcast behavior supports notifications and audit copies, while also making subscriber count part of capacity planning.
Routing key is dot-separated (e.g., "sensor.temperature.zone1").
Best for multi-attribute rules; supports x-match: all or x-match: any.

Major section

Real-World Case Study: Industrial IoT with AMQP Exchange Routing

Network load: 4,800 x 3 = 14,400 publishes/second.

Three backend systems consume this data differently.
The rates and latency goals below are planning assumptions, not measured plant results.
Producer sends 3 publish operations per reading; serialization work depends on whether it reuses the encoded body.

Major section

Real-World Case Study: Industrial IoT with AMQP Exchange Routing (continued)

In this deliberately replicated-publish design, producers publish each message 3 times; direct exchanges can also route one publish to multiple queues when bindings share an exact key.

Network load: 4,800 publishes/second (each message published once).
Broker routes each message to 2 queues (dashboard + one specialist).
Each filtered consumer receives 4,800 msg/s but discards 50%; the dashboard uses all messages.

Topic exchange routing a sensor topic to matching queues

Major section

Worked Example: Industrial IoT Message Routing with Topic Exchange

Result: This single PUBLISH reaches 2 queues (Maintenance + Dashboard), one fewer than fanout's 3 deliveries for this message (a 33% reduction).

50 machines × 120 messages/hour = 6,000 publishes/hour.
With topic exchange: 6,000 publishes routed to 8,400 queue deliveries (average 1.4 queues per message).
With fanout exchange: 6,000 publishes × 3 queues = 18,000 deliveries (about 114% more than topic routing).

Fanout exchange broadcasting one published message to every bound queue

Major section

Common Mistake: Publishing to the Default Exchange Without Understanding Routing

The Error: Developers new to AMQP use exchange='' (the default exchange) thinking it simplifies publishing, but they create messages that route directly to a queue by name instead of using exchange-based routing logic.

With default exchange in this scenario: Modifying 200 publishers at an assumed 2 hours each is 400 developer hours before shared testing.
With topic exchange: A new queue and binding can be added without changing those publishers; deployment and validation still take time.
The default exchange remains useful for deliberate publishing to a known queue.

Deck summary

Key takeaways

Different exchange types provide flexible routing patterns for various messaging scenarios.

Each bound queue receives its own copy, allowing independent consumers to progress at different rates.
Network load: 4,800 x 3 = 14,400 publishes/second.
In this deliberately replicated-publish design, producers publish each message 3 times; direct exchanges can also route one publish to multiple queues when bindings share an exact key.
Result: This single PUBLISH reaches 2 queues (Maintenance + Dashboard), one fewer than fanout's 3 deliveries for this message (a 33% reduction).

Retrieval practice

Recall check 1 of 5

Broker Bex says: answer from memory, then check your reasoning.

Q1A routing key sensor.temperature.zone1 is published to a topic exchange. Which binding pattern will NOT match this routing key?

AThe sensor.temp.# binding requires temp, not temperature.

BThe sensor.# binding matches all words after sensor.

CThe sensor.*.zone1 binding matches one middle word.

DThe # binding matches any sequence of topic words.

Show answer

Answer: A Topic exchange wildcards: * matches exactly one dot-separated word, and # matches zero or more.

Q2What retains routed AMQP messages until a consumer can receive them?

ABroker

BProducer

CExchange

DQueue

Show answer

Answer: D It retains routed messages until a consumer can receive them.

Retrieval practice

Recall check 2 of 5

Broker Bex says: answer from memory, then check your reasoning.

Q3Complete the AMQP exchange declaration and queue binding:

Achannel.exchange_declare(exchange='sensors', exchange_type='topic')

Bchannel.exchange_create(name='sensors', type='topic')

Cchannel.declare_exchange('sensors', 'topic')

Dchannel.exchange('sensors', exchange_type='topic')

Show answer

Answer: A In AMQP, exchanges are declared with exchange_declare() specifying the type (direct, fanout, topic, headers).

Retrieval practice

Recall check 3 of 5

Broker Bex says: answer from memory, then check your reasoning.

Q4An industrial monitor uses routing keys of the form machine.{line}.{id}.{type}, such as machine.line1.id042.vibration. Publishers do not add a sensor_type header. A maintenance queue must receive all and only vibration readings using one binding. Which listed exchange and binding fit?

ATopic exchange with binding pattern machine.*.*.vibration

BDirect exchange with binding key machine.vibration

CFanout exchange (broadcasts all messages to the maintenance queue)

DHeaders exchange with header attribute sensor_type: vibration

Show answer

Answer: A see answers page

Retrieval practice

Recall check 4 of 5

Broker Bex says: answer from memory, then check your reasoning.

Q5A building publishes keys of the form sensor.{type}.{floor}, such as sensor.temperature.floor3 and sensor.humidity.floor1, without custom type headers. One queue must receive all temperature readings from all floors and nothing else using one binding. Which listed exchange and binding fit?

AFanout exchange with no binding key

BTopic exchange bound to sensor.temperature.*

CDirect exchange, binding sensor.temperature.

DHeaders exchange with x-match: any

Show answer

Answer: B see answers page

Retrieval practice

Recall check 5 of 5

Broker Bex says: answer from memory, then check your reasoning.

Q6An AMQP 0-9-1 broker sends channel.close for a channel-level declaration mismatch while the shared TCP connection stays open. Fifty sensor streams use separate channels on that connection. What happens to the other 49 channels?

AAll channels are closed because they share the same TCP connection

BThe broker closes the connection and all channels must reconnect

CThey continue operating normally because channel errors are isolated

DThe other channels pause until the errored channel is manually reset

Show answer

Answer: C A channel.close for a declaration mismatch is scoped to that channel. The other 49 channels can remain usable while the affected channel is reopened and its topology contract checked. A separate connection-level failure would affect them all.

Print reference

Answers 1 of 4

Answer key.

A · Topic exchange wildcards: * matches exactly one dot-separated word, and # matches zero or more.
D · It retains routed messages until a consumer can receive them.
A · In AMQP, exchanges are declared with exchange_declare() specifying the type (direct, fanout, topic, headers).

Print reference

Answers 2 of 4

Answer key.

A · The routing key has 4 levels: machine.{line}.{id}.{type}. To match ALL vibration sensors regardless of line or machine ID, you need a topic exchange with wildcards. The pattern machine.*.*.vibration matches: - machine.line1.id042.vibration ✓ - machine.line2.id103.vibration ✓ But rejects: - machine.line1.id042.temperature ✗ (temperature, not vibration) Why other options fail: - B (Direct): Requires exact match; machine.vibration won't match machine.line1.id042.vibration - C (Fanout): Broadcasts ALL messages including temperature, pressure, etc. (wastes bandwidth) - D (Headers): Requires publishers to set headers; less efficient than routing key for hierarchical data.

Print reference

Answers 3 of 4

Answer key.

B · A topic exchange with the pattern sensor.temperature.* matches any routing key that starts with sensor.temperature. followed by exactly one word (the floor number). A direct exchange requires an exact match so it cannot match multiple floors with one binding. A fanout exchange would broadcast all messages to all queues regardless of type, delivering humidity and pressure readings too.

Print reference

Answers 4 of 4

Answer key.

C · A channel.close for a declaration mismatch is scoped to that channel. The other 49 channels can remain usable while the affected channel is reopened and its topology contract checked. A separate connection-level failure would affect them all.