Why Redis Expiration and RabbitMQ Dead‑Letter Queues Are Unsuitable for Delayed Tasks and Recommended Alternatives

Hello everyone, I am Lei.

Recently I read a post by teacher Aniu titled "Leaders: Anyone still using scheduled tasks to close orders, step down immediately!" and found several flaws in the proposed solutions, which I discuss here.

In e‑commerce and payment systems, orders that are placed but not paid are often closed after a certain timeout. Major platforms implement this with sub‑second accuracy, but how?

Common implementations include:

1. Using delayed delivery features of message queues such as RocketMQ, RabbitMQ, Pulsar. 2. Using Redisson's DelayedQueue .

Some widely spread solutions have fatal defects and should not be used for delayed tasks:

1. Redis key‑expiration listeners. 2. RabbitMQ dead‑letter queues. 3. Non‑persistent time wheels.

Redis Expiration Listener

The Redis official documentation states that expired events are generated when the server actually deletes the key, not when the TTL reaches zero.

Basically expired events are generated when the Redis server deletes the key and not when the time to live theoretically reaches the value of zero

Redis deletes expired keys via an offline scanning task that removes a portion of expired keys; on access it performs lazy deletion. Redis does not guarantee immediate deletion at the configured expiration time, and notifications can be delayed by minutes.

Key‑space notifications use a fire‑and‑forget strategy and can lose events if the subscriber disconnects. This solution is "lower" than scanning the database and should be avoided.

Another expert tested and warned against over‑reliance on Redis expiration listeners; interested readers should investigate further.

RabbitMQ Dead Letter

Dead letters in RabbitMQ occur when:

Message is negatively acknowledged (e.g., channel.basicNack ) with requeue=false .

Message exceeds its TTL in the queue.

Queue length exceeds its maximum.

If a dead‑letter exchange is configured, dead letters are routed there.

Creating a dead‑letter queue involves:

Creating an exchange to act as the dead‑letter exchange.

Configuring x-dead-letter-exchange and x-dead-letter-routing-key on the business queue.

Creating a queue bound to the dead‑letter exchange and listening to it.

The purpose is to store undelivered messages for inspection and possible re‑delivery, but delivery time is not guaranteed; subsequent messages may not be dead‑lettered until the first one is processed.

To address timing issues, RabbitMQ provides the delayed‑message‑exchange plugin, which is the recommended way to implement delayed messaging.

Using Redis expiration listeners or RabbitMQ dead‑letter queues for delayed tasks is an unintended use of middleware and often leads to hidden problems such as lack of consistency, reliability, low throughput, or resource leaks. It is better to use dedicated components for their intended purpose.

Time Wheel

A time wheel is an efficient data structure for timers, but most implementations are in‑memory only and lack persistence; if the process crashes, all scheduled tasks are lost, so use with caution.

Redisson DelayQueue

Redisson's delay queue is built on a Redis sorted set where the score is the delivery timestamp. A background task scans the set with zrangebyscore for due messages and moves them to a ready list.

As long as Redis does not crash, messages are not lost, making it a viable fallback when better solutions are unavailable.

When the database index is well designed, scanning for unfinished orders does not incur as much overhead as expected. Combining a Redis‑based delay queue with periodic database scans can provide compensation for middleware failures.

Conclusion

1. Prefer message queues with built‑in delayed delivery such as RocketMQ or Pulsar. 2. If a professional queue is unavailable, consider Redisson delay queue but add compensation for Redis crashes. 3. If Redisson is unsuitable, a time wheel can be used, but ensure robust protection mechanisms because restarts are frequent. 4. Never use Redis expiration listeners for delayed tasks.

Source: cnblogs.com/Finley/p/16395466.html