Reliability & Delivery

Reliability is a chain, not a switch

“Don’t lose my messages” sounds like one feature. It is actually a chain of independent links, and a message is only as safe as the weakest one. A message can be lost:

Between the publisher and the broker — the publish never arrived, or arrived at an exchange that routed it nowhere.
Inside the broker — the broker restarted and the message wasn’t written to disk.
Between the broker and the consumer — the consumer took the message, crashed mid-work, and it was already deleted.

Turning on one safeguard and assuming you’re covered is the classic mistake. Real reliability means closing every gap in the chain.

flowchart LR
  p["Publisher"] -->|"gap 1:
publisher confirms"| x["Exchange"]
  x -->|"gap 2:
mandatory + durable"| q["Queue"]
  q -->|"gap 3:
persistence"| disk["Disk"]
  q -->|"gap 4:
manual ack"| c["Consumer"]

Every link in the delivery chain can lose a message

What this module covers

Lesson	The gap it closes
Publisher confirms	Publisher → broker: know the broker actually accepted your message
Dead-letter exchanges	Handle messages that can’t be processed instead of losing or looping them
Delivery guarantees	Understand at-most-once, at-least-once, and the “exactly-once” myth
Durability & persistence	Survive a broker restart — durable queues and persistent messages

The recurring theme: at-least-once

RabbitMQ’s whole reliability model points at one guarantee: at-least-once delivery. Every safeguard — confirms, acks, persistence — exists to make sure a message is delivered at least once, even across crashes and restarts.

The price of “at least once” is that you may occasionally get a message more than once (a redelivery after a crash). So the other half of reliable design lives in your code: making consumers idempotent so a duplicate does no harm. Reliability is a partnership — RabbitMQ won’t drop your message, and you make sure processing it twice is safe.