Choosing the Right Delayed Task Solution: Redis Expiration, RabbitMQ Dead Letter, Time Wheel, and Redisson DelayQueue

Introduction

In e‑commerce and payment systems, orders that are not paid must be closed after a precise time window (often within a 1‑second error margin). Common approaches include using message‑queue delayed delivery (RocketMQ, RabbitMQ, Pulsar) or Redisson's DelayedQueue.

Some widely‑circulated solutions have fatal flaws and should not be used for delayed tasks:

Redis expiration listening

RabbitMQ dead‑letter queues

Non‑persistent time wheels

Redis Expiration Listening

The Redis official documentation states that expired events are generated only when the server actually deletes the key, not when the TTL reaches zero. Redis expires keys via periodic offline scans and lazy checks on access, offering no guarantee of immediate deletion or notification.

Key‑space notifications follow a “fire‑and‑forget” model, meaning subscribers can lose events if they disconnect. This approach is less reliable than database scans and should be avoided for scheduling.

RabbitMQ Dead Letter

Dead letters are messages that become dead under conditions such as negative acknowledgment without requeue, TTL expiration, or queue length overflow. When a dead‑letter exchange is configured, these messages are routed to a dead‑letter queue.

Dead‑letter queues store undelivered messages for troubleshooting and re‑delivery but do not guarantee delivery timing; subsequent messages may be delayed until the first dead letter is processed.

RabbitMQ provides an official delayed‑message plugin (rabbitmq‑delayed‑message‑exchange) that should be used instead of relying on dead‑letter queues for delayed tasks.

Time Wheel

A time wheel is an efficient in‑memory data structure for scheduling, but most implementations lack persistence. If the process crashes, all scheduled tasks are lost, making it risky for production use.

Redisson DelayQueue

Redisson DelayQueue implements a delayed queue using a Redis sorted set (zset) where each element’s score is the delivery timestamp. A background task periodically scans the set with zrangebyscore to move due messages to a ready list.

When Redis remains operational, the DelayQueue guarantees no message loss. It can be combined with database scans as a compensation mechanism to handle Redis failures.

Conclusion

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

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

When Redisson is unsuitable, a time wheel can be used, but ensure additional protection like database scans.

Never use Redis expiration listening for delayed tasks.