AMQP · Study deck
AMQP Reliability: Delivery Controls
Some messages are casual status updates, and some are smoke alarms.
Broker Bex is your guide for this deck.

After studying this chapter
Learning objectives
You will be able to:
- Explain: For a smoke alarm, we need publisher confirms -- the broker texts you back saying 'got it!' If you don't hear back within a few seconds, you send it again.
- Explain: the LED added, "And the fire system uses consumer acknowledgments -- it tells the broker 'message received and acted on' only AFTER it actually starts the sprinklers.
- Explain: "I sent a smoke alarm message, but the fire system says it never arrived!" Temperature Terry was panicking. "What if there's a real fire?".
- Explain: This runway does not promise exactly-once work.
Major section
In 60 Seconds
The sender may try again.
- Reliable delivery then depends on whether the receiver can recognise the same command and keep the physical action bounded.
- A protocol is a shared set of rules for exchanging data.
- AMQP means Advanced Message Queuing Protocol.
- A broker is the service that accepts and routes messages.
Major section
In 60 Seconds (continued)
A microcontroller is a small computer built to read inputs and control outputs.
- This runway does not promise exactly-once work.
- AMQP reliability requires configuring both durable queues AND persistent messages -- missing either means data loss on broker restart.
- Key patterns include competing consumers for load distribution and prefetch counts to prevent consumer starvation.
Major section
The Reliability Relay Race
"I sent a smoke alarm message, but the fire system says it never arrived!" Temperature Terry was panicking. "What if there's a real fire?".
- the microcontroller calmed him down. "That's why we use reliability patterns, Sammy.
Major section
The Reliability Relay Race (continued)
For a smoke alarm, we need publisher confirms -- the broker texts you back saying 'got it!' If you don't hear back within a few seconds, you send it again.
- the LED added, "And the fire system uses consumer acknowledgments -- it tells the broker 'message received and acted on' only AFTER it actually starts the sprinklers.
- If the fire system crashes before sending that ACK, the broker assumes it failed and sends the message to a backup system.".
- "What about my regular temperature readings?" asked the battery. "Those can use fire-and-forget -- no confirmations needed.
Major section
Interactive: Throughput vs Latency Tradeoff
Key Insight: Disk I/O is the limiting factor for persistent messages.
- A 10 ms disk latency limits throughput to 100 msg/sec per connection.
- Transient messages with 0.5 ms memory latency can handle 2,000 msg/sec - a 20x difference.
- For high-throughput workloads (>10K msg/sec), either use transient messages or employ broker clustering with message sharding.
Try it: Interactive: Throughput vs Latency Tradeoff in the chapter
Major section
Worked Example: Designing a Multi-Consumer Order Processing System
Scenario: An e-commerce warehouse has 50 robotic picking stations that receive orders from a central system.
- Orders must be distributed evenly across available robots, and each order should be processed exactly once.
- If a robot fails mid-processing, the order must be reassigned.
Major section
Interactive: Prefetch Calculator
Key Takeaway: The optimal prefetch count depends on your target latency and processing time.
- For most competing consumer scenarios with variable processing, prefetch=1 is the safest choice.
- Higher prefetch values are only beneficial when processing times are consistent and you need to hide network latency.
Try it: Interactive: Prefetch Calculator in the chapter
Major section
Worked Example: Multi-Tier Alert Routing with Priority Queues
Scenario: A manufacturing plant has sensors monitoring temperature, pressure, and vibration across 10 production lines.
- Result: Critical alerts use persistent delivery with quorum queues for high availability - they survive broker failures and are guaranteed to reach on-call engineers.
- Warning alerts are persistent but use standard queues.
Major section
Common Misconception: "AMQP Guarantees Message Delivery"
Misconception:: Many developers assume that using AMQP automatically guarantees messages will be delivered and processed, leading to data loss in production.
- Reality:: AMQP provides mechanisms for reliability, but doesn't enforce them by default.
Deck summary
Key takeaways
The sender may try again.
- A microcontroller is a small computer built to read inputs and control outputs.
- "I sent a smoke alarm message, but the fire system says it never arrived!" Temperature Terry was panicking. "What if there's a real fire?".
- For a smoke alarm, we need publisher confirms -- the broker texts you back saying 'got it!' If you don't hear back within a few seconds, you send it again.
- Key Insight: Disk I/O is the limiting factor for persistent messages.
Retrieval practice
Recall check

Broker Bex says: answer from memory, then check your reasoning.
Q1A consumer receives an AMQP message representing a payment transaction. It calls basic_nack(delivery_tag=tag, requeue=False). Where does the message go next?
Show answer
Answer: B basic_nack(requeue=False) routes the message to the dead-letter exchange if configured, or drops it.
Print reference
Answers
Answer key.
- B · basic_nack(requeue=False) routes the message to the dead-letter exchange if configured, or drops it.