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.

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

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.
iotclass.org

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.

Why it matters

Manual acknowledgments prevent message loss during consumer crashes (unlike auto-ack which discards on failure), while dead-letter queues catch rejected or expired messages.

iotclass.org

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.
iotclass.org

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.
iotclass.org

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.
iotclass.org

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.

Numbers to remember

10 msA 10 ms disk latency limits throughput to 100 msg/sec per connection.

Try it: Interactive: Throughput vs Latency Tradeoff in the chapter

iotclass.org

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.

Why it matters

Result: Orders are distributed across 50 robots using competing consumers pattern. prefetch_count=1 ensures even distribution regardless of robot speed.

iotclass.org

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

iotclass.org

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.

Why it matters

For high-volume, low-value telemetry, transient delivery with bounded queues prevents backpressure from crashing the broker.

iotclass.org

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.
iotclass.org

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.
iotclass.org

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?

AThe message is returned to the head of the original queue and redelivered immediately
BThe message is forwarded to the dead-letter exchange if one is configured, or dropped permanently if not
CThe message is acknowledged and removed from the broker permanently
DThe broker retries delivery to the same consumer up to three times before giving up
Show answer

Answer: B basic_nack(requeue=False) routes the message to the dead-letter exchange if configured, or drops it.

iotclass.org

Print reference

Answers

Answer key.

  1. B · basic_nack(requeue=False) routes the message to the dead-letter exchange if configured, or drops it.
iotclass.org