AMQP · Study deck

AMQP Delivery: Guarantees and Acknowledgements

An AMQP message is a parcel with a label, a body, and a delivery receipt path.

Broker Bex is your guide for this deck.

archmessagesdelivery

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

After studying this chapter

Learning objectives

You will be able to:

Analyze Message Structure: Distinguish the role of AMQP header, properties, and body sections and explain how each field affects message routing and delivery
Configure Delivery Modes: Select appropriate message persistence, priority, and time-to-live (TTL) settings to match application reliability requirements
Implement Delivery Guarantees: Evaluate and implement at-most-once, at-least-once, and exactly-once semantics based on data criticality and overhead trade-offs
Apply Acknowledgments: Demonstrate correct use of publisher confirms and consumer acknowledgments to construct reliable messaging pipelines

Major section

In 60 Seconds

Losing one reading may be acceptable.

Losing the order is not.
Repeating the order may also create two visits, so the sender needs evidence of the receiver's final result, not only evidence that a message left.
AMQP is a set of messaging rules for moving labelled messages through a message service.
The application must close its own result.

Major section

In 60 Seconds (continued)

For each message class, record identity, sender, receiver, allowed age, repeat rule, order need, storage need, acceptance point, and final business result.

Stored delivery does not prove that the receiver acted, and a confirmation does not prove that the message was true.
Under the Hood explains message parts, acknowledgments, persistence, confirmation windows, dead-letter handling, and why exactly-once wording needs a stated boundary.
The protocol supports three delivery guarantee levels -- at-most-once, at-least-once, and exactly-once -- implemented through publisher confirms and consumer acknowledgments.

Major section

The Tracked Package

"My temperature alert says the warehouse is overheating, but the cooling system never turned on!" Temperature Terry cried. "What happened to my message?".

When you sent your alert, did you ask for a publisher confirm?" Sammy looked blank. "That's like asking the post office to text you when they receive your package.
If the cooling system crashes before saying ACK, the broker sends the message again.
Engineers can check it later to find out what went wrong.

Major section

Message Structure

Reliability depends on the routing, persistence, timing, and identity metadata the message carries.

An AMQP message consists of multiple sections that provide metadata and payload.
Delivery controls such as durability and priority belong in the header; identifiers and content description travel as properties; the application value remains in the body.

AMQP message structure with header, properties, and body sections

Major section

Delivery Guarantees

Once the parcel is shaped, choose the promise: speed and low overhead, or stronger protection against loss.

AMQP provides configurable delivery semantics to match application requirements.
Acknowledgment and retry trade possible loss for possible duplication; stronger coordination costs more state.
Fastest but may lose messages.
Message guaranteed to be delivered, but may arrive multiple times.

AMQP delivery guarantee levels: at-most-once, at-least-once, exactly-once

Major section

Consumer Acknowledgments

After broker receipt, ACK and NACK behavior decides whether a queued message is removed, retried, or routed elsewhere.

An ACK permits removal; a NACK must explicitly choose requeue or dead-letter handling.
This decision is why prefetch and idempotency belong beside acknowledgment policy rather than being tuned independently.
Prefetch controls how many unacknowledged messages a consumer can hold.

Consumer acknowledgment flow with success ACK and failure NACK paths

Major section

Dead Letter Queues

The last part of the reliability chain is evidence: failed messages should land somewhere inspectable.

Dead letter queues (DLQ) capture messages that cannot be processed successfully.
The final queue is a holding and evidence boundary, not proof of recovery; operators still need a bounded retry or repair decision.

Dead letter queue pattern for handling failed messages

Deck summary

Key takeaways

Losing one reading may be acceptable.

For each message class, record identity, sender, receiver, allowed age, repeat rule, order need, storage need, acceptance point, and final business result.
"My temperature alert says the warehouse is overheating, but the cooling system never turned on!" Temperature Terry cried. "What happened to my message?".
Reliability depends on the routing, persistence, timing, and identity metadata the message carries.
Once the parcel is shaped, choose the promise: speed and low overhead, or stronger protection against loss.

Retrieval practice

Recall check 1 of 4

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

Q1Per this chapter's Properties Section, which two AMQP properties work together to implement a request/reply (RPC) pattern over queues?

ACorrelation-ID (links the reply to its original request) and Reply-To (the queue where the response should be sent)

BContent-Type and Content-Encoding, since they identify how the response body is formatted

CMessage-ID and Timestamp, since they uniquely order requests and replies chronologically

DApp-ID and Type, since they identify which application should reply

Show answer

Answer: A

Retrieval practice

Recall check 2 of 4

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

Q2A water utility deploys AMQP to transmit two data streams: (1) water flow meter readings every 2 seconds across 1,000 sensors, and (2) automated valve-close commands triggered when a leak is detected. Which delivery modes should be configured, and why does the distinction matter at scale?

AAt-most-once for flow readings; at-least-once for valve-close commands

BExactly-once for both, since water infrastructure is safety-critical

CAt-least-once for both, since guaranteed delivery is always safer

DAt-most-once for both, since lower overhead improves system scalability

Show answer

Answer: A The key principle is matching delivery guarantee to data criticality.

Retrieval practice

Recall check 3 of 4

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

Q3Per this chapter's Publisher Confirms section, what is the practical difference between the synchronous and asynchronous confirm code patterns shown?

AThe synchronous pattern blocks and raises an exception if the message isn't confirmed; the asynchronous pattern is non-blocking and reports confirm/reject status through a callback

BThe synchronous pattern uses a callback function, while the asynchronous pattern raises an exception on failure

CBoth patterns are functionally identical; the only difference is which broker they connect to

DThe asynchronous pattern requires exactly-once delivery mode, while the synchronous pattern requires at-most-once

Show answer

Answer: A

Retrieval practice

Recall check 4 of 4

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

Q4Per this chapter's DLQ Triggers list, which of the following does the chapter NOT list as a way a message ends up in a dead-letter queue?

AThe publisher's confirm times out without receiving a Basic.Ack from the broker

BThe consumer rejects the message with requeue=false

CThe message's TTL expires

DThe queue's maximum length is exceeded

Show answer

Answer: A The chapter's DLQ Triggers list has exactly four entries: consumer rejects with requeue=false, message TTL expires, queue length exceeded, and message rejected after max retries.

Print reference

Answers

Answer key.

A
A · The key principle is matching delivery guarantee to data criticality.
A
A · The chapter's DLQ Triggers list has exactly four entries: consumer rejects with requeue=false, message TTL expires, queue length exceeded, and message rejected after max retries.