This assessment tests your understanding of AMQP core concepts: exchange type selection for different routing scenarios, routing key pattern matching with wildcards, queue configuration for reliability, and the differences between AMQP’s broker-mediated routing and MQTT’s simpler pub/sub model.
63.1 Learning Objectives
For Beginners: AMQP Assessment
This assessment tests your understanding of AMQP messaging concepts. Think of it as a practice quiz that helps you check whether you understand how messages flow through exchanges, queues, and bindings. Working through these questions helps reinforce what you have learned and identifies areas worth reviewing.
Learning Objectives
By the end of this chapter, you will be able to:
Assess your comprehension of AMQP core concepts including exchanges, queues, and bindings
Publisher Confirms: Asynchronous broker acknowledgment to producers confirming message persistence in the queue
Dead Letter Exchange: Secondary exchange receiving rejected, expired, or overflowed messages for error handling
This chapter provides knowledge assessment through interactive quizzes covering AMQP fundamentals, exchange types, routing patterns, and reliability features. Use these questions to validate your understanding before moving to implementation.
Putting Numbers to It
Routing design can be evaluated with delivered-message load:
With 300-byte average payload+metadata, topic filtering sends about \(350 \times 300 = 105{,}000\) B/s (about 102.5 KB/s). A fanout design would push all 1,000 msg/s (about 293 KB/s), nearly 3x more downstream traffic and unnecessary consumer load.
63.3 Prerequisites
Before taking this assessment, you should be familiar with:
AMQP Core Concepts: Exchange types, routing patterns, and the post office analogy
Test your understanding of fundamental concepts with these questions.
Quiz 1: Exchange Types and Routing
Binding Patterns Needed:
# Maintenance queue needs these bindings:queue.bind( exchange="sensor-exchange", routing_key="sensor.temperature.#"# Matches ALL temperature sensors)queue.bind( exchange="sensor-exchange", routing_key="sensor.vibration.#"# Matches ALL vibration sensors)# What gets matched:"sensor.temperature.line1.machine3" YES Matches sensor.temperature.#"sensor.temperature.line2.machine7" YES Matches sensor.temperature.#"sensor.vibration.line1.machine5" YES Matches sensor.vibration.#"sensor.vibration.line2.machine7" YES Matches sensor.vibration.#"sensor.pressure.line1.machine3" NO No match (pressure not bound)
Wildcard Comparison:
**Single-level wildcard (*):**
Pattern: "sensor.*.line1"
Matches: sensor.temperature.line1 YES
sensor.vibration.line1 YES
Does NOT match: sensor.temperature.line1.machine3 NO (too many levels)
Multi-level wildcard (#):
Pattern: "sensor.temperature.#"
Matches: sensor.temperature.line1 YES
sensor.temperature.line1.machine3 YES
sensor.temperature.anything.else YES
Does NOT match: sensor.vibration.line1.machine3 NO (different type)
Why Other Options Are Wrong:
A: Direct Exchange with partial routing keys:
# Direct exchange requires EXACT matchqueue.bind(exchange, routing_key="sensor.temperature")# This published message DOES NOT MATCH:publish(routing_key="sensor.temperature.line1.machine3")# Because "sensor.temperature" is not equal to "sensor.temperature.line1.machine3"
Direct exchanges can’t do pattern matching - they need exact routing key match.
B: Fanout Exchange:
# Fanout broadcasts to ALL bound queues, ignoring routing keyfanout.bind(maintenance_queue) # Gets EVERYTHING# Maintenance receives:sensor.temperature.line1.machine3 YES (wanted)sensor.vibration.line2.machine7 YES (wanted)sensor.pressure.line1.machine3 NO (NOT wanted - wasted bandwidth)sensor.humidity.line2.machine9 NO (NOT wanted - wasted processing)
Fanout can’t filter - it’s all-or-nothing broadcasting. Maintenance system would be overwhelmed with unwanted data.
D: Headers Exchange:
# Headers exchange routes based on message headers, not routing keyheaders_exchange.bind( maintenance_queue, headers={"sensor_type": "temperature,vibration"}, match="all"# or "any")# Problems:# 1. Sensors must set headers (additional overhead)# 2. Comma-separated values require custom logic# 3. Less efficient than topic routing# 4. Not the AMQP idiom for this use case
Headers exchange works but is unnecessarily complex for hierarchical routing.
Performance Comparison:
Scenario: 100 sensors, 10 msg/sec each = 1000 msg/sec total
33% temperature, 33% vibration, 34% other types
Topic Exchange (Correct):
Messages to maintenance queue: 660 msg/sec (temp + vibration only)
Broker routing operations: 1000 pattern matches/sec
Network bandwidth to maintenance: 660 x 200 bytes = 132 KB/sec
Fanout Exchange (Wrong):
Messages to maintenance queue: 1000 msg/sec (ALL types)
Network bandwidth to maintenance: 1000 x 200 bytes = 200 KB/sec
Application must filter: 340 unwanted messages/sec
Extra processing: 51% more CPU, 51% more network