RabbitMQ Publisher Confirms: Reliable Message Publishing

Publisher confirms close the gap between a producer calling convertAndSend and the broker actually persisting the message to disk. Without them, the method returns after writing to the TCP buffer — if the broker crashes before completing the disk write, the message is lost and the producer never finds out.

How confirms work:

• In confirm mode, the broker sends a basic.ack back to the producer after the message is on disk; if it cannot handle the message, it sends basic.nack
• This is the opposite direction from consumer acks — confirms are broker-to-producer, consumer acks are consumer-to-broker; they cover opposite sides of the delivery pipeline

Confirms vs returns — two different failure modes:

• A confirm tells you the broker received and persisted the message; but if the exchange has no matching binding, the message is silently discarded — the confirm still comes back positive
• Publisher returns catch routing failures; enable them with publisher-returns: true and mandatory: true on the template — without mandatory, unroutable messages are dropped without triggering the callback

Implementation in Spring AMQP:

• Use CORRELATED confirm type and attach a CorrelationData with a unique ID to each publish; CorrelationData.getFuture() resolves when the broker responds, allowing per-message retry logic
• For production-grade reliability, back pending messages with a database outbox rather than in-memory maps — in-memory pending maps lose data on crash

I recommend always enabling publisher confirms in production for any business-critical message, and combining them with publisher returns to cover both persistence failures and routing failures.