RabbitMQ Acknowledgment Modes: Auto vs Manual

Message acknowledgment controls when RabbitMQ considers a message successfully delivered. The Spring AMQP terminology trips people up because Spring has three modes that don't map directly to AMQP's two protocols.

The three Spring modes:

• NONE is true fire-and-forget — the broker deletes the message on delivery before processing completes; if the consumer crashes, the message is gone; use only for metrics or telemetry where loss is acceptable
• AUTO is the safe default — it uses manual acknowledgment at the protocol level but handles it automatically; the container acks after your listener returns without throwing, and nacks with requeue on exception; covers most use cases without writing ack code
• MANUAL is for workflows needing explicit control: payment processing where you want to ack only after the database transaction commits, or where you need to distinguish transient failures (requeue for retry) from permanent ones (dead-letter immediately)

Prefetch — the critical companion:

• Without prefetch limits, the broker floods one consumer with messages while others sit idle; set prefetch to 1 for the fairest distribution across competing consumers, or 10–20 for a throughput-fairness balance
• requeue=false in basicNack triggers DLX routing; requeue=true puts the message back at the queue head and can create a hot-loop on poison messages

The silent failure mode in manual ack:

• Forgetting to ack or nack on any code path leaves messages unacked; the prefetch limit fills up; the consumer silently stops receiving with no error in logs — no exception, just a hung consumer

I recommend AUTO as the default and only switching to MANUAL when you need to explicitly tie the ack to a database transaction commit or to distinguish failure types.