Master RabbitMQ Reliability: ConfirmCallback, TTL, and Dead‑Letter Queues

RabbitMQ Advanced Features – Reliable Delivery and Consumption

Message reliability can be compromised when producers send data to RabbitMQ and network issues or broker failures cause loss during transmission, in‑memory buffering, or consumer crashes. Ensuring that messages reach the broker and are processed correctly requires explicit confirmation mechanisms.

ConfirmCallback in Practice

Enabling ConfirmCallback

In older versions, developers implement the ConfirmCallback interface to receive acknowledgments after a message reaches an exchange. spring.rabbitmq.publisher-confirms=true In newer versions, the default NONE disables publishing confirms; setting CORRELATED enables callbacks after the exchange receives the message.

spring.rabbitmq.publisher-confirm-type=correlated

Code Example

@Autowired
private RabbitTemplate template;

@Test
void testConfirmCallback() {
    template.setConfirmCallback(new RabbitTemplate.ConfirmCallback() {
        @Override
        public void confirm(CorrelationData correlationData, boolean ack, String cause) {
            System.out.println("confirm====>");
            System.out.println("confirm====ack=" + ack);
            System.out.println("confirm====cause=" + cause);
            // TODO: update message status based on ack
        }
    });
    template.convertAndSend(RabbitMQConfig.EXCHANGE_NAME, "order.new", "New order arrived 1");
}

To simulate failures, change the target exchange for each test run. Note that enabling confirms adds overhead and may reduce throughput, so use it only for critical messages.

RabbitMQ TTL and Dead‑Letter Queues

What is TTL?

TTL (time‑to‑live) defines how long a message may remain in a queue before it is considered dead. It can be set per‑message or per‑queue, with the latter being the most common approach.

What is a Dead‑Letter Queue?

A dead‑letter queue stores messages that cannot be delivered or processed, such as rejected messages, expired messages, or messages that exceed the queue's maximum length.

Reasons for Dead‑Lettering

Message rejected with requeue=false Message TTL expired

Queue reached its maximum length

Dead‑Letter Exchange Flow

When a message becomes dead, the broker republishes it to a dead‑letter exchange, which routes it to the configured dead‑letter queue.

The RabbitMQ management console can be used to create a dead‑letter exchange, bind it to a dead‑letter queue, and set queue‑level TTL (using the x-message-ttl argument) or per‑message TTL (using the expiration property).

Interview Questions on RabbitMQ Core Skills

1. What is a virtual host?

A virtual host (vhost) isolates a set of exchanges, queues, bindings, and permissions, allowing multiple logical environments within a single broker instance.

2. How to choose a queue product?

Common options include ActiveMQ, Kafka, RocketMQ, and RabbitMQ. Each has trade‑offs in throughput, durability, language support, and operational complexity.

3. How to avoid duplicate consumption?

Message brokers do not guarantee exactly‑once delivery; applications must enforce idempotency. A common approach is to use Redis for deduplication.

// Redis setNX example
boolean flag = jedis.setNX(key);
if (flag) {
    // process message
} else {
    // ignore duplicate
}

// Redis incr example
int num = jedis.incr(key);
if (num == 1) {
    // process message
} else {
    // ignore duplicate
}

Both methods require appropriate expiration settings for high‑volume scenarios.