Why Redis Expiration Listeners Fail for Delayed Tasks and Better Alternatives

Background

In e‑commerce and payment systems, orders that are abandoned after placement must be automatically closed after a precise timeout; platforms like Taobao and JD achieve sub‑second accuracy, prompting the question of how such timing is implemented.

Common Approaches

Use delayed delivery features of message queues such as RocketMQ, RabbitMQ, Pulsar.

Use Redisson’s DelayedQueue built on Redis.

Why Redis Expiration Listener Is Unsuitable

Redis key‑space notifications are generated only when the server actually deletes a key, not when the TTL reaches zero. The server removes expired keys via periodic scans or lazy checks on access, so notifications can be delayed by minutes. Moreover, notifications follow a fire‑and‑forget model; if a subscriber disconnects, all events emitted during the outage are lost. Consequently, relying on Redis expiration events for precise delayed tasks is error‑prone and should be avoided.

RabbitMQ Dead‑Letter Queue

A dead‑letter (DL) message in RabbitMQ is created when a message is negatively acknowledged without requeue, exceeds its TTL, or the queue length limit is reached. To use a DL queue:

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

Configure the business queue with x-dead-letter-exchange and x-dead-letter-routing-key pointing to the DL exchange.

Create a queue bound to the DL exchange and consume from it.

DL queues store messages that were not consumed normally, aiding troubleshooting and redelivery, but they do not guarantee delivery timing; a message becomes a dead‑letter only after the first message triggers the DL condition.

RabbitMQ provides an official delayed‑message plugin ( rabbitmq-delayed-message-exchange) that should be preferred for delayed delivery.

Time Wheel

A time wheel is an efficient in‑memory data structure for scheduling future tasks. Most implementations lack persistence, so a process crash discards all pending tasks. Use it cautiously and consider additional protection mechanisms.

Redisson DelayQueue

Redisson DelayQueue implements a delayed queue using a Redis sorted set (ZSET). Each entry’s score is the delivery timestamp. A background scanner runs zrangebyscore to fetch due messages and moves them to a ready list.

When Redis remains operational, the delay queue does not lose messages. In environments without a better solution, it can be a viable option, especially when combined with a database‑scan fallback to compensate for Redis failures.

Conclusion

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

If a professional queue is unavailable, consider Redisson DelayQueue but design compensation for Redis crashes.

When neither is feasible, a time wheel can be used, but ensure robust recovery mechanisms.

Never rely on Redis expiration listeners for implementing delayed tasks.