Auto‑Cancel Unpaid Orders After 30 Minutes with RabbitMQ: TTL + DLX vs Delayed Message Plugin

Interview focus : The interviewer wants to verify that you understand the complete TTL‑plus‑DLX workflow for delayed messages, can draw the message flow diagram, know alternative solutions, and are aware of the head‑blocking issue of the classic approach.

Core answer : RabbitMQ does not support delayed messages natively; two practical implementations exist:

TTL + Dead‑Letter Queue (DLX) : Set a TTL on a message; when it expires the broker routes it to a dead‑letter exchange, which forwards it to a dead‑letter queue that the consumer listens to. This requires no extra plugins.

Delayed‑Message Plugin ( rabbitmq_delayed_message_exchange): Install the plugin, declare an exchange of type x‑delayed‑message, and set the delay directly on the message. The exchange stores the message in the internal Mnesia database until the delay elapses.

Detailed TTL + DLX workflow :

Producer sends a message to a “delay queue” (e.g., delay.queue) that has no consumers.

The message sits in the queue until its TTL expires.

When TTL expires, the broker automatically forwards the message to the dead‑letter exchange ( dlx.exchange) which routes it to the dead‑letter queue ( dlx.queue).

Consumer listens on the dead‑letter queue and receives the message after the intended delay.

Spring Boot configuration (excerpt):

@Bean
public DirectExchange dlxExchange() {
    return new DirectExchange("dlx.exchange");
}

@Bean
public Queue dlxQueue() {
    return new Queue("dlx.queue");
}

@Bean
public Binding dlxBinding() {
    return BindingBuilder.bind(dlxQueue())
        .to(dlxExchange()).with("dlx.routing.key");
}

@Bean
public Queue delayQueue() {
    Map<String, Object> args = new HashMap<>();
    args.put("x-dead-letter-exchange", "dlx.exchange");
    args.put("x-dead-letter-routing-key", "dlx.routing.key");
    return new Queue("delay.queue", true, false, false, args);
}

rabbitTemplate.convertAndSend("normal.exchange", "delay.routing.key", message,
    msg -> { msg.getMessageProperties().setExpiration("600000"); return msg; });

Head‑blocking pitfall : RabbitMQ checks expiration only on the first message in the queue. If the head message has not expired, later messages that have already timed out remain blocked, causing delayed delivery.

Mitigation : Create separate delay queues for each distinct delay (e.g., delay.queue.5m, delay.queue.10m, delay.queue.30m) so that all messages in a queue share the same TTL, eliminating the blockage. This approach increases the number of queues, so for many delay values the plugin solution is preferable.

Delayed‑Message Plugin configuration :

# Enable the plugin
rabbitmq-plugins enable rabbitmq_delayed_message_exchange

@Bean
public CustomExchange delayedExchange() {
    Map<String, Object> args = new HashMap<>();
    args.put("x-delayed-type", "direct");
    return new CustomExchange("delayed.exchange", "x-delayed-message", true, false, args);
}

rabbitTemplate.convertAndSend("delayed.exchange", "order.routing.key", "订单已创建", 
    msg -> { msg.getMessageProperties().setDelay(30 * 60 * 1000); return msg; });

@RabbitListener(queues = "order.queue")
public void handleOrder(String message) {
    log.info("收到延迟消息：{}", message);
}

The plugin avoids head‑blocking because the exchange holds the message in Mnesia until the delay expires, then routes it normally.

Comparison summary (key dimensions):

Head‑blocking : Present in TTL + DLX, absent in plugin.

Architecture complexity : Higher for TTL + DLX (needs DLX and multiple queues); lower for plugin (single exchange).

Additional dependencies : None for TTL + DLX; plugin requires installing rabbitmq_delayed_message_exchange.

Delay precision : TTL + DLX can be imprecise due to blockage; plugin provides precise delays.

Performance : TTL + DLX keeps messages in memory (lower memory pressure); plugin stores messages in Mnesia, which may affect performance for very large volumes.

Suitable scenarios : TTL + DLX works when delay types are few and fixed; plugin is better when many different delay intervals are needed.

Recommendation : If the environment permits installing the plugin, use the delayed‑message‑exchange approach for its simplicity and lack of head‑blocking. Otherwise, adopt TTL + DLX but partition messages into separate delay queues to avoid blockage.

High‑frequency follow‑up questions :

When to choose RabbitMQ delayed messages vs. Redis delayed queues? Redis ZSET + polling is lighter but less reliable; RabbitMQ is preferred if already in use.

Where does the delayed‑message plugin store messages and what are its performance limits? Messages reside in Mnesia (Erlang’s built‑in DB); large volumes can become a bottleneck, making it unsuitable for millions of delayed tasks.

What are common implementations for order timeout cancellation? Options include RabbitMQ delayed messages, Redis key expiration notifications, periodic DB polling, or time‑wheel algorithms; RabbitMQ and Redis are the most common in production.

Memory aids :

Two schemes: TTL + DLX is classic (has head‑blocking); delayed‑message plugin is recommended (no blocking, but needs plugin).

Head‑blocking: FIFO only checks the queue head; separating queues by delay eliminates the issue.

One‑sentence summary : RabbitMQ lacks native delayed messaging, so the classic TTL + dead‑letter‑queue method (with a head‑blocking caveat) and the recommended x‑delayed‑message plugin are the two viable solutions, and mentioning both plus the blockage fix earns full marks in an interview.