RabbitMQ
Acknowledgements & Delivery Guarantees
Use consumer acks correctly so messages are never silently lost on failure.
RabbitMQ uses consumer acknowledgements to know when a message has been successfully handled. With manual acks (the safe default for important work), the broker keeps a delivered message in an "unacknowledged" state until the consumer sends a basic.ack. If the consumer crashes or its connection drops before acking, the broker requeues the message for another consumer — giving at-least-once delivery.
A courier requiring a signature on delivery. Until you sign (ack), the parcel is still "out for delivery" and will be re-attempted if the courier loses it. Sign too early at the door before checking the contents (auto-ack) and a damaged parcel is your problem.
Key Concepts
1
The dangerous alternative is auto-ack (acknowledge on delivery), which is effectively at-most-once: if the consumer dies mid-processing, the message is already considered delivered and is lost. A consumer can also basic.nack or basic.reject a message, optionally with requeue=false to send it to a dead-letter exchange instead of looping forever.
2
Because redelivery is possible, consumers should be idempotent — the same message may be processed more than once.
3
What the interviewer is probing.
What the interviewer is probing.
4
1. "What does manual acknowledgement give you?" *Probing:* the core. *Stalls:* "Control." *Moves
up:* the message is only removed once processing succeeded, so a consumer crash redelivers rather
than losing it.
1. "What does manual acknowledgement give you?"
5
2. "What is the danger of auto-ack?" *Probing:* the trap. *Stalls:* "None." *Moves up:* the
message is considered delivered on send, so a crash mid-processing loses it entirely.
2. "What is the danger of auto-ack?"
6
3. "What is the difference between nack and reject?" *Probing:* the detail. *Stalls:* "Nothing."
*Moves up:* nack can apply to multiple messages; both can requeue or discard depending on the
requeue flag.
3. "What is the difference between nack and reject?"
7
4. "What is the risk of requeueing on failure?" *Probing:* the practical failure. *Stalls:*
"None." *Moves up:* a poison message loops forever at full speed — which is what a dead letter
exchange and a retry count are for.
4. "What is the risk of requeueing on failure?"