RabbitMQ 4.x Message Reliability: Acknowledgments, Retries, Dead Letters, and Idempotency

Baseline: RabbitMQ 4.x or current supported 3.13+, Java client version compatible with the server. Do not use latest, and do not use the default password.

1. Production Pipeline

Publisher -> Exchange -> Queue -> Consumer
     |                         |
 publisher confirm          ack/retry/dead letter

Publisher confirms address "whether the message was received by the Broker," while consumer acks address "whether the message was successfully processed." These are two different things.

2. Publisher-Side Reliability

Enable publisher confirms—only consider a publish successful after receiving Broker acknowledgment. Applications must still handle nacks, connection drops, and timeouts, and use business message IDs for idempotency.

Message persistence, persistent exchanges/queues, and confirms all reduce the risk of loss, but that doesn't mean the business has already been successfully processed. For critical events, it's recommended to use a local message table or Outbox, putting database state and pending messages in the same transaction.

3. Consumer-Side Processing

Consumers should ack after successful business processing; transient failures can be retried a limited number of times, and messages that cannot be processed go to the dead letter queue. Retries must have limits on count and backoff—don't requeue indefinitely, or you'll create a hot loop.

Consumption logic must be idempotent. Network retries, consumer restarts, and lost acks can all result in the same message being delivered again.

4. High Availability and Delayed Messages

For high availability scenarios, prioritize evaluating quorum queues. Classic queues, mirror policies, and delayed plugin behavior depend on RabbitMQ version—don't just copy deployment commands from the 3.8 era.

For delayed messages, evaluate TTL + DLX, plugins, Streams, or business schedulers. Before choosing, confirm order, retry, capacity, and operational costs.

5. Security and Monitoring

Create minimal-privilege users for each application, enable TLS and access control on the management interface. Monitor confirms, nacks, unacked, queue depth, consumer latency, retry counts, and dead letter quantities. Set prefetch to avoid a single consumer holding too many unacknowledged messages at once.