What are RabbitMQ publisher confirms in Spring AMQP, and what problem do they solve?

## The problem With raw AMQP, `basic.publish` has no response. When you call `rabbitTemplate.convertAndSend(exchange, routingKey, payload)`, the method returns as soon as the bytes are handed to the client library's channel. If the broker crashes, is out of disk, or the connection drops mid-flight, the producer never finds out — the message is silently lost. This is 'fire and forget'. ## Publisher confirms **Publisher confirms** (a.k.a. 'confirms' or 'publisher acknowledgements') are a RabbitMQ protocol extension. When enabled on a channel, the broker sends back an **asynchronous acknowledgement** for each published message: - **ack** — the broker has taken responsibility for the message. For a persistent message routed to a durable queue, this means it was written to disk; for a transient message it means it was routed to (accepted by) all the matching queues. - **nack** — the broker could NOT take responsibility (e.g. an internal error, out of resources). Nacks are rare. Confirms are **asynchronous and out-of-band**: publishing stays fast; the acks stream back separately, possibly batched, and not necessarily in send order. ## Enabling it in Spring AMQP Confirms are configured on the `CachingConnectionFactory`: ```java CachingConnectionFactory cf = new CachingConnectionFactory("localhost"); cf.setPublisherConfirmType(CachingConnectionFactory.ConfirmType.CORRELATED); ``` Three modes: - `ConfirmType.NONE` (default) — confirms off. - `ConfirmType.SIMPLE` — enables confirms and lets you call `channel.waitForConfirms()` via `rabbitTemplate.invoke(...)` for a synchronous, blocking wait. - `ConfirmType.CORRELATED` — enables confirms and delivers the result to a callback, carrying a `CorrelationData` you attached at send time so you can match the ack to the specific message. Then on the `RabbitTemplate` you register a `RabbitTemplate.ConfirmCallback`: ```java template.setConfirmCallback((correlationData, ack, cause) -> { if (ack) { /* broker accepted */ } else { /* nack: cause has the reason */ } }); ``` ## What a confirm does and does NOT mean - It **does** mean the broker received/stored/routed the message. - It does **not** mean any consumer processed it — that's consumer acknowledgements, a separate concept. - An ack does **not** mean the message reached a queue if there was no matching queue: an unroutable message is still **acked** (the broker accepted it, then dropped it). Detecting 'accepted but not routed to any queue' needs the **mandatory flag + returns**, which is a separate mechanism. ## Gotchas - Requires the `CachingConnectionFactory` (channels must be cached/tracked). - Callbacks run on a **listener/amqp thread**, not your publishing thread — keep them fast and thread-safe. - There is no automatic timeout: if a confirm never arrives (connection lost), your callback simply never fires unless you add your own timeout handling. ## When to use Use confirms whenever losing a produced message is unacceptable (payments, orders, event sourcing). Combine with **persistent messages + durable queues + mandatory returns** for end-to-end producer reliability.