AMQP · Study deck
AMQP Delivery: Sizing and Reliability Contracts
An AMQP message is a parcel with a label, a body, and a delivery receipt path.
Broker Bex is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: The practical audit question is therefore always, "where can the message be acknowledged but not yet recoverable?" Publisher confirms answer the producer side, persistence answers the broker restart side, and manual acknowledgements answer the consumer side.
- Explain: Worked example -- a meter reading that must not be lost.: The producer opens confirm mode, publishes with delivery-mode=2 to a durable queue, and waits for the broker's confirm before deleting its local copy.
- Explain: If four consumers each use basic.qos(prefetch_count=20), as many as 80 messages can be delivered but unacknowledged at once.
Major section
Putting Numbers to It
For telemetry with 120-byte payloads, nearly half the bandwidth is protocol overhead.
- Batching 10 readings into one 1,200-byte message improves efficiency from 51% to 91%, saving $(10 \times 236B) - (1,200B + 116B) = 1,044B$ per 10 readings (44% reduction).
- Conclusion:: The telemetry (98% of messages) uses fire-and-forget, keeping broker load minimal.
- That overhead is waste for data that is replaced every 5 seconds.
Major section
AMQP Delivery Reliability Chain Contracts
The message reaches a queue, the worker writes the incident, and then the worker crashes before it says the job is done.
- One durable setting cannot protect a different gap in the chain.
- The chain can notify and retain evidence, but it must not be the sole route to stop immediate harm.
Major section
AMQP Delivery Reliability Chain Contracts (continued)
Treating those as one chain keeps operators from over-trusting a single durable setting.
- This opening does not promise exactly-once physical action.
- AMQP Message Delivery teaches message structure, delivery modes, publisher confirms, consumer acknowledgments, prefetch, dead-letter queues, and delivery sizing.
- Retrying from a message id makes the duplicate detectable.
Major section
AMQP Delivery Reliability Chain Contracts (continued)
The consumer reads, writes the reading to the database, and only then sends basic.ack.
- This page tightens the contract that connects those pieces: no single flag makes delivery reliable, and each acknowledgment only means something inside its scope.
- Concrete chain example: a gateway sends a valve-state alarm and keeps its local copy until the broker sends a publisher confirm.
- That requeue is why at-least-once can *duplicate*.
Major section
AMQP Delivery Reliability Chain Contracts (continued)
If the broker confirms and then restarts, the durable queue and persistent message are what make the alarm still appear after recovery.
- If the consumer receives the alarm, writes it to an incident table, and crashes before basic.ack, the broker requeues the unacknowledged delivery on channel close.
- The practical audit question is therefore always, "where can the message be acknowledged but not yet recoverable?" Publisher confirms answer the producer side, persistence answers the broker restart side, and manual acknowledgements answer the consumer side.
- Retryable work waits in the TTL queue and returns; excessive failures move to parking with context intact.
Major section
AMQP Delivery Reliability Chain Contracts (continued)
If four consumers each use basic.qos(prefetch_count=20), as many as 80 messages can be delivered but unacknowledged at once.
- The two disk settings only work together: a persistent message in a transient queue is not saved, and a transient message in a durable queue is not saved either.
- Publisher confirms even close the fsync race -- the broker only confirms a persistent message routed to a durable queue after it is on disk.
- A worker crash with 17 unacked messages does not lose those messages; they return to the queue when the channel closes.
Major section
AMQP Delivery Reliability Chain Contracts (continued)
The DLX can route it to a retry queue with x-message-ttl=30000; after 30 seconds that retry queue dead-letters it back to the main exchange.
- Worked example -- a meter reading that must not be lost.: The producer opens confirm mode, publishes with delivery-mode=2 to a durable queue, and waits for the broker's confirm before deleting its local copy.
- That count is what lets a retry loop give up after N attempts instead of cycling a poison message forever.
- The next worker may see the same alarm, so the team must prevent a second incident without losing the first.
Deck summary
Key takeaways
For telemetry with 120-byte payloads, nearly half the bandwidth is protocol overhead.
- The message reaches a queue, the worker writes the incident, and then the worker crashes before it says the job is done.
- Treating those as one chain keeps operators from over-trusting a single durable setting.
- The consumer reads, writes the reading to the database, and only then sends basic.ack.
- If the broker confirms and then restarts, the durable queue and persistent message are what make the alarm still appear after recovery.
Retrieval practice
Recall check 1 of 3
Broker Bex says: answer from memory, then check your reasoning.
Q1Place each AMQP delivery event where it lives so you can tell broker acceptance, queue routing, and consumer completion apart.
Show answer
Answer: A Separate publish acceptance, broker routing and retention, and consumer settlement so you can prove exactly how far a message travelled.
Q2Complete the AMQP publisher with persistent delivery mode and publisher confirms:
Show answer
Answer: A Publisher confirms are enabled with confirm_delivery().
Retrieval practice
Recall check 2 of 3
Broker Bex says: answer from memory, then check your reasoning.
Q3Per this chapter's sizing worked example (four consumers, each with prefetch_count=20), why does a worker crash while holding 17 unacknowledged messages not lose those 17 messages?
Show answer
Answer: A Unacknowledged messages are still owned by the queue until acked.
Retrieval practice
Recall check 3 of 3
Broker Bex says: answer from memory, then check your reasoning.
Q4A durable queue holds messages published with delivery-mode 1 (transient). The broker restarts. What happens, and what is the minimal fix for zero loss?
Show answer
Answer: A Queue durability keeps the definition; message persistence keeps the contents.
Print reference
Answers
Answer key.
- A · Separate publish acceptance, broker routing and retention, and consumer settlement so you can prove exactly how far a message travelled.
- A · Publisher confirms are enabled with confirm_delivery().
- A · Unacknowledged messages are still owned by the queue until acked.
- A · Queue durability keeps the definition; message persistence keeps the contents.