Choosing the Right Delayed Task Solution: Message Queues, Redis, RabbitMQ DLX, Time Wheel, and Redisson DelayQueue

Preface

In e‑commerce and payment scenarios, orders that are not paid are automatically closed after a precise time window; the article explores how such timing is implemented.

Common Approaches

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

Use Redisson’s DelayQueue.

Solutions to Avoid

Redis key‑space expiration listening.

RabbitMQ dead‑letter queue.

Non‑persistent time wheel.

Redis Expiration Listening

Redis key‑space notifications are generated only when the server actually deletes a key, not when TTL reaches zero, and they use a fire‑and‑forget strategy, so they are unreliable for precise delayed tasks.

RabbitMQ Dead Letter

Dead letters are messages that are negatively acknowledged, exceed TTL, or overflow the queue. Creating a dead‑letter exchange and queue can capture such messages, but delivery time is not guaranteed, making it unsuitable for accurate scheduling.

Using Redis expiration listening or RabbitMQ dead‑letter queues for delayed tasks misuses middleware and can lead to consistency, reliability, and throughput issues.

Time Wheel

A time wheel is an efficient in‑memory data structure for timers, but most implementations lack persistence; a process crash will lose all scheduled tasks.

Redisson DelayQueue

Redisson implements a delay queue on top of a Redis sorted set, scanning by score to move ready messages. It survives Redis restarts but still requires compensation mechanisms for Redis failures.

Conclusion

Prefer message queues with built‑in delayed delivery (RocketMQ, Pulsar, etc.).

If such queues are unavailable, consider Redisson DelayQueue with appropriate fallback strategies.

When neither is possible, a time wheel can be used, but add database‑scan compensation.

Never use Redis expiration listening for delayed tasks.