Reliability: Acks, Durability, Prefetch & Dead Letters

Acknowledgment

A consumer explicitly acks a message once processed; RabbitMQ only removes it then. If a consumer crashes before acking, the message gets redelivered — preventing loss from mid-processing failures. This at-least-once guarantee means duplicate delivery IS possible (e.g. an ack lost to a network blip) — design consumers to be idempotent (processing the same message twice produces the same safe end result, like checking "was this order already charged?" before charging).

Durability

A durable queue + persistent messages survive a broker restart (written to disk, not just held in memory). Skip this and an in-memory-only queue's messages are lost if RabbitMQ crashes — important for anything where losing a message (like a payment task) is unacceptable.

Prefetch Count

Caps how many unacked messages a consumer can hold at once — prevents one fast-connecting-but-slow-processing consumer from hoarding messages while others sit idle. A low prefetch (like 1) ensures fair distribution across competing consumers.

Dead Letter Queues

Messages repeatedly nacked or expired get redirected to a dead letter queue/exchange instead of looping forever or vanishing silently — a dedicated place to inspect and debug failed processing.

The Web App + Worker Pattern

A web app quickly responds to a request while publishing a message ("send welcome email") for a separate worker service to process asynchronously — avoiding making the user wait for slow, non-critical work. Trade-off: the caller can no longer assume completion by the time it returns, and tracing a request across an async, multi-step flow is more involved than a single synchronous call chain.