Choosing the Right Delayed Task Implementation: Avoid Redis Expiration and RabbitMQ Dead‑Letter Queues

Preface

In e‑commerce and payment scenarios, orders that are placed but not paid need to be closed after a precise time window, often within a 1‑second error margin; the article explores how this is achieved.

Typical implementations include:

Using delayed delivery features of message queues like RocketMQ, RabbitMQ, Pulsar.

Using Redisson's DelayedQueue.

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

Redis expiration listeners.

RabbitMQ dead‑letter queues.

Non‑persistent time wheels.

Redis Expiration Listener

The Redis official manual states that expired events are generated when the server 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 implements expiration by offline scanning and lazy deletion; it does not guarantee immediate deletion or notification, and notifications can be delayed by minutes. Keyspace notifications use a fire‑and‑forget strategy, so clients may miss events during disconnections. This approach is considered low‑quality and should be avoided.

RabbitMQ Dead‑Letter

Dead letters are generated when a message is negatively acknowledged without requeue, exceeds its TTL, or the queue length limit is reached.

Message negatively acknowledged (basicNack) with requeue = false.

Message lives longer than its TTL.

Queue length exceeds the maximum.

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

The creation steps are:

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

Configure x‑dead‑letter‑exchange and x‑dead‑letter‑routing‑key on the business queue.

Create a queue on the dead‑letter exchange and listen to it.

Dead‑letter queues store undelivered messages for troubleshooting and re‑delivery, but they do not guarantee delivery timing; later messages may expire before being dead‑lettered. RabbitMQ provides a delayed‑message plugin (rabbitmq‑delayed‑message‑exchange) that is recommended for delayed messaging.

Using Redis expiration listeners or RabbitMQ dead‑letter queues for delayed tasks misuses middleware, leading to consistency, reliability, throughput, and resource‑leak issues; professional components should be used for professional tasks.

Time Wheel

A time wheel is an efficient data structure for timed tasks, but most implementations are in‑memory only and lack persistence; a process crash will lose all scheduled tasks, so caution is advised.

Redisson DelayQueue

Redisson DelayQueue implements a delayed queue on top of Redis sorted sets; items have scores equal to their delivery timestamps, and a background scan moves due items to a ready list.

It guarantees no message loss as long as Redis does not crash, making it a viable fallback when better solutions are unavailable.

When database indexes are well designed, scanning the database for unfinished orders is not as costly as expected, and combining Redisson DelayQueue with periodic database scans can provide compensation for middleware failures.

Conclusion

Prefer message queues with built‑in delayed delivery such as RocketMQ or Pulsar.

If professional queues are unavailable, consider Redisson DelayQueue with compensation mechanisms for Redis failures.

If Redisson is unsuitable, a time wheel can be used, but ensure robust protection mechanisms like database scanning.

Never use Redis expiration listeners for delayed tasks.