Implementing Precise Order Timeout with RabbitMQ Delayed Message Plugin in Spring Boot

Hello everyone, I'm Ah Q. Recently my leader revived an old e‑commerce project and asked me to refactor the code, especially the part that closes timed‑out orders using a scheduled task. This approach has serious drawbacks, which I will analyze and replace with a more reliable solution.

Why scheduled tasks are unsuitable

Closing timed‑out orders requires a consistent timeout for each order. Using a scheduled task makes it hard to choose an appropriate polling interval: a small interval causes high I/O load, while a large interval leads to significant delay and inconsistency, as illustrated by the example where a 30‑minute interval can miss the exact timeout by up to 25 minutes.

Therefore we need to abandon the scheduled‑task method.

Using a delayed queue (RabbitMQ)

We first try to implement the timeout with RabbitMQ's dead‑letter queue mechanism. By setting Time To Live (TTL) on messages and configuring x-dead-letter-exchange and x-dead-letter-routing-key , messages that expire become dead letters and are routed to a dedicated dead‑letter queue.

Key points:

TTL can be set per message (ideal for delayed queues) or per queue.

The smaller TTL value takes precedence when both message and queue TTL are set.

Dead‑letter messages are identified when they are rejected, expire, or the queue reaches its max length.

Configuration example (Spring Boot):

@Configuration
public class DelayQueueRabbitConfig {
    public static final String DLX_QUEUE = "queue.dlx"; // dead‑letter queue
    public static final String DLX_EXCHANGE = "exchange.dlx"; // dead‑letter exchange
    public static final String DLX_ROUTING_KEY = "routingkey.dlx";
    public static final String ORDER_QUEUE = "queue.order"; // order delayed queue
    public static final String ORDER_EXCHANGE = "exchange.order"; // order exchange
    public static final String ORDER_ROUTING_KEY = "routingkey.order";

    @Bean
    public Queue dlxQueue() { return new Queue(DLX_QUEUE, true); }

    @Bean
    public DirectExchange dlxExchange() { return new DirectExchange(DLX_EXCHANGE, true, false); }

    @Bean
    public Binding bindingDLX() { return BindingBuilder.bind(dlxQueue()).to(dlxExchange()).with(DLX_ROUTING_KEY); }

    @Bean
    public Queue orderQueue() {
        Map
params = new HashMap<>();
        params.put("x-dead-letter-exchange", DLX_EXCHANGE);
        params.put("x-dead-letter-routing-key", DLX_ROUTING_KEY);
        return new Queue(ORDER_QUEUE, true, false, false, params);
    }

    @Bean
    public DirectExchange orderExchange() { return new DirectExchange(ORDER_EXCHANGE, true, false); }

    @Bean
    public Binding orderBinding() { return BindingBuilder.bind(orderQueue()).to(orderExchange()).with(ORDER_ROUTING_KEY); }
}

Sending a message with a per‑message TTL:

@RequestMapping("/order")
public class OrderSendMessageController {
    @Autowired
    private RabbitTemplate rabbitTemplate;

    @GetMapping("/sendMessage")
    public String sendMessage() {
        String delayTime = "10000"; // 10 seconds
        rabbitTemplate.convertAndSend(DelayQueueRabbitConfig.ORDER_EXCHANGE,
            DelayQueueRabbitConfig.ORDER_ROUTING_KEY,
            "Send Message!",
            message -> {
                message.getMessageProperties().setExpiration(delayTime);
                return message;
            });
        return "ok";
    }
}

Consuming the message:

@Component
@RabbitListener(queues = DelayQueueRabbitConfig.DLX_QUEUE)
public class OrderMQReceiver {
    @RabbitHandler
    public void process(String message) {
        System.out.println("OrderMQReceiver received: " + message);
    }
}

Testing shows that messages are consumed after the specified delay, but a problem appears when multiple messages with different TTLs are sent: the queue’s FIFO nature blocks later messages until earlier ones expire.

Problem solution with the x‑delay‑message plugin

The RabbitMQ x-delay-message plugin stores delayed messages in the internal Mnesia database and releases them when the delay expires, eliminating the FIFO blockage. Installation steps:

Download the plugin (e.g., v3.8.0.ez ) and place it in /usr/local/soft/rabbitmq_server-3.7.14/plugins .

Enable it with rabbitmq-plugins enable rabbitmq_delayed_message_exchange .

Configuration using the plugin:

@Configuration
public class XDelayedMessageConfig {
    public static final String DIRECT_QUEUE = "queue.direct";
    public static final String DELAYED_EXCHANGE = "exchange.delayed";
    public static final String ROUTING_KEY = "routingkey.bind";

    @Bean
    public Queue directQueue() { return new Queue(DIRECT_QUEUE, true); }

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

    @Bean
    public Binding orderBinding() { return BindingBuilder.bind(directQueue()).to(delayedExchange()).with(ROUTING_KEY).noargs(); }
}

Sending delayed messages with the plugin:

@RestController
@RequestMapping("/delayed")
public class DelayedSendMessageController {
    @Autowired
    private RabbitTemplate rabbitTemplate;

    @GetMapping("/sendManyMessage")
    public String sendManyMessage() {
        send("Delay 10 seconds", 10000);
        send("Delay 2 seconds", 2000);
        send("Delay 5 seconds", 5000);
        return "ok";
    }

    private void send(String msg, Integer delayTime) {
        rabbitTemplate.convertAndSend(XDelayedMessageConfig.DELAYED_EXCHANGE,
            XDelayedMessageConfig.ROUTING_KEY,
            msg,
            message -> {
                message.getMessageProperties().setDelay(delayTime);
                return message;
            });
    }
}

Consuming:

@Component
@RabbitListener(queues = XDelayedMessageConfig.DIRECT_QUEUE)
public class DelayedMQReceiver {
    @RabbitHandler
    public void process(String message) {
        System.out.println("DelayedMQReceiver received: " + message);
    }
}

Test results show messages are received in the correct order according to their individual delays, solving the earlier FIFO blockage.

Limitations

Delayed messages are stored in a single‑node Mnesia table; if the node restarts or the plugin is disabled, those messages are lost.

The plugin is not suited for very large volumes of delayed messages (tens of thousands or more) because each delayed message creates an Erlang timer, which can cause timer contention and drift.

Overall, using RabbitMQ’s delayed‑message plugin provides precise, per‑message delay handling for order timeout scenarios, avoiding the pitfalls of scheduled tasks and traditional dead‑letter queues.