Why Using Redis Expiration Listener and RabbitMQ Dead‑Letter Queues for Delayed Tasks Is a Bad Idea

In e‑commerce and payment scenarios, orders that are not paid need to be closed after a certain timeout, and many systems rely on Redis expiration events, RabbitMQ dead‑letter queues, or simple time wheels to achieve this.

Redis Expiration Listener

The Redis documentation states that expired events are generated when the server actually deletes the key, not when the TTL reaches zero. Redis deletes keys either via periodic offline scans or lazy checks on access, and it does not guarantee immediate deletion or notification; notifications can be delayed by minutes and are fire‑and‑forget, meaning clients may miss events during disconnections. Therefore, using Redis expiration as a reliable timer is unsafe and should be avoided.

RabbitMQ Dead‑Letter Queue

A message becomes a dead letter when it is negatively acknowledged without requeue, exceeds its TTL, or the queue length limit is reached. If a dead‑letter exchange is configured, the message is routed there, but RabbitMQ does not guarantee delivery time for dead letters. The recommended approach is to use the official delayed‑message plugin (rabbitmq‑delayed‑message‑exchange) instead of relying on dead‑letter queues for timing.

Time Wheel

Time wheels are efficient in‑memory data structures for scheduling, but most implementations lack persistence. If the process crashes, all scheduled tasks are lost, making them a high‑risk choice for production delayed‑task systems.

Redisson DelayQueue

Redisson implements a delay queue on top of Redis sorted sets (ZSET). Elements are stored with a score equal to the delivery timestamp, and a background scan using zrangebyscore moves due items to a ready list. This approach retains messages as long as Redis does not crash and can serve as a fallback when dedicated message‑queue solutions are unavailable.

Conclusion

Prefer message queues with native delayed delivery such as RocketMQ or Pulsar.

If a professional queue is unavailable, consider Redisson DelayQueue but add compensation mechanisms for Redis failures.

When neither is feasible, a time wheel can be used, but ensure additional safeguards like database scans.

Never use Redis expiration listening for delayed tasks.

Recommended reading: "Leader: Anyone Still Using Scheduled Tasks to Close Orders, Get Out!" and "Do Not Over‑Depend on Redis Expiration Listening".