RabbitMQ acknowledgements

Consumer acknowledgements tell the broker when work is safely done. Ack after the side effect is durable — database commit, idempotent marker written, or external call completed with compensating logic. Nack with requeue retries transient failures; reject without requeue sends to dead-letter when the message is poison.

Publisher confirms acknowledge that the broker accepted the message before you tell users success. Manual ack mode is default for reliability; auto-ack loses messages if the consumer crashes mid-processing. At-least-once delivery means duplicates are possible without idempotent handlers.

On interviews: walk through ack timing for a payment handler, explain nack versus reject, and connect publisher confirms to user-facing API responses.

Common pitfalls: acking before database commit; infinite requeue on permanent errors; no publisher confirms while returning HTTP 200; assuming exactly-once because manual ack is enabled.

The trade-off is flexibility versus complexity—know when the simpler path is enough.

Checklist:

• Ack only after safe processing.
• Use nack/reject with explicit requeue policy.
• Enable publisher confirms on critical publishes.
• Design handlers for duplicate delivery.