AMQP · Study deck

AMQP Reliability: Persistence and Routing Patterns

AMQP 0-9-1 passes messages through a broker.

Broker Bex is your guide for this deck.

implmisconceptions

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

After studying this chapter

Learning objectives

You will be able to:

Diagnose Common AMQP Pitfalls: Analyze the top 5 implementation mistakes that cause data loss and system failures, and explain why each leads to production incidents
Configure Message Persistence Correctly: Justify why both durable queues AND persistent messages (delivery_mode=2) are required for reliability, and implement both settings together
Apply Wildcard Patterns Accurately: Distinguish between * (exactly one word) and # (zero or more words) in topic exchanges, and select the correct wildcard for variable-depth routing hierarchies
Select AMQP vs MQTT Appropriately: Compare protocol overhead metrics (bandwidth, RTT, memory, battery) and justify protocol selection decisions based on quantified device constraints

Major section

In 60 Seconds

A protocol is an agreed set of exchange rules.

Advanced message queuing protocol (AMQP) is used to exchange messages through named services and rules.
A broker is a service that accepts messages and routes or stores them for receivers.
The sender may have retried after a lost reply.
The service may have redelivered after a worker stopped.

Major section

In 60 Seconds (continued)

Neither event proves that the system is broken; the unsafe part is acting twice without a clear rule.

One passed path cannot prove exactly-once business action or endless storage.
It proves the stated exchange under stated limits.
The deeper sections examine the common myths and show which mechanism, record, and application rule can support a narrower claim.

Major section

The "It Should Work" Trap

"I set my queue to durable, so my messages will survive a server restart, right?" Sammy the Sensor said confidently.

My light readings vanished when the server rebooted." Max nodded. "Another common one: people think more consumers always means faster processing.

Major section

The Pitfall

A durable queue survives broker restart but arrives empty if messages were transient.

Quantified Impact: A durable queue alone does not preserve transient messages through a broker restart; publish persistent messages and use publisher confirms when this durability matters.

Major section

Putting Numbers to It

If $Q$ transient messages remain queued at restart, up to $Q$ messages are at risk; at 200 B payload each, payload loss is $Q \times 200$ B.

The assumed write-wait cost should be weighed against messages still queued at restart; the chapter’s 259 GB total counts every message published over 30 days and is not a restart-loss estimate.

Major section

The Pitfall

For constrained devices (battery, bandwidth), MQTT is often superior.

In this 10,000-message example, the protocol-overhead row uses 2 bytes for MQTT and 8–20 bytes for AMQP, so MQTT carries less framing.
The resulting totals are 2.02 MB and 2.18 MB respectively, again favoring MQTT for this payload mix.

Major section

The Pitfall

Exactly-once requires application-level idempotency (deduplication using message IDs).

Failure mode: If a worker performs an action and fails before its acknowledgment reaches the broker, a redelivery may repeat that action.
Persist the event ID and the business effect atomically, or make the action itself idempotent.

Major section

Try It: Duplicate Message Simulator

Adjust the number of commands, glitch probability, and see how idempotency keys prevent dangerous duplicate executions in a chemical tank filling scenario.

Simulate what happens when network glitches cause message redelivery.

Deck summary

Key takeaways

A protocol is an agreed set of exchange rules.

Neither event proves that the system is broken; the unsafe part is acting twice without a clear rule.
"I set my queue to durable, so my messages will survive a server restart, right?" Sammy the Sensor said confidently.
A durable queue survives broker restart but arrives empty if messages were transient.
If $Q$ transient messages remain queued at restart, up to $Q$ messages are at risk; at 200 B payload each, payload loss is $Q \times 200$ B.

Retrieval practice

Recall check 1 of 4

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

Q1Per this chapter's persistence truth table, what happens to a queue declared with durable=True but messages published with delivery_mode=1 (transient), after a broker restart?

AQueue and messages are lost because a durable declaration protects only the queue definition, not its contents.

BQueue vanishes but transient messages remain independently recoverable.

CQueue and transient messages both survive like delivery-mode 2.

DDurable queue remains; transient messages vanish on restart.

Show answer

Answer: D see answers page

Retrieval practice

Recall check 2 of 4

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

Q2Per this chapter's Misconception 2 impact data, what happened to a smart building system that used sensor.temperature.* instead of sensor.temperature.#?

AIt duplicated each zone-level sensor reading for three months

BIt crashed the broker from a routing-key length overflow

CIt missed multi-zone data from more than 5,000 sensors for three months

DIt matched all sensors but delayed reports by three months

Show answer

Answer: C see answers page

Retrieval practice

Recall check 3 of 4

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

Q3A payment consumer uses auto_ack=True and accepts deliveries one at a time. It completed messages #1–49, received #50, then crashed before saving its payment. Messages #51–200 had not been delivered. How many of these messages are lost from the queue without a completed payment?

AOne: auto-ack removed message 50 before its payment was saved.

BZero: the broker retains message 50 until its payment is saved.

C150: undelivered messages 51 through 200 are already lost.

DFifty: completed payments 1 through 49 vanish on restart.

Show answer

Answer: A In auto_ack mode, the broker considers a delivery handled when it sends it, without waiting for processing.

Retrieval practice

Recall check 4 of 4

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

Q4A consumer executes the chemical-tank ADD 100ml command, sends a manual ACK, but the connection closes before the broker receives that ACK. The broker requeues the unacknowledged delivery and a second consumer executes it again. Why did the tank gain 200ml?

AACK was lost on connection close; broker requeued the unacked command, so it ran again.

BThe command itself was corrupted in transit, so the broker automatically resends a fresh copy

CThe consumer explicitly requests a retry because the tank level sensor reported an error

DAMQP always executes every command exactly twice by default as a safety margin

Show answer

Answer: A The broker cannot infer a completed physical action from the consumer's local state.

Print reference

Answers 1 of 3

Answer key.

D · The chapter's four-row truth table shows durable=True, delivery_mode=1 as the 'TRAP' configuration (per the Try It tool's label): the queue definition exists after restart, but every transient message it held is gone, so the queue simply comes back empty.

Print reference

Answers 2 of 3

Answer key.

C · Because matches exactly one word, sensor.temperature. only matches 3-segment routing keys. Multi-zone sensors publish deeper keys (e.g. sensor.temperature.room1.zone2), which * cannot match, so the chapter's smart building example silently lost all of that deeper data for 3 months until the binding was corrected to sensor.temperature.#.
A · In auto_ack mode, the broker considers a delivery handled when it sends it, without waiting for processing.

Print reference

Answers 3 of 3

Answer key.

A · The broker cannot infer a completed physical action from the consumer's local state.