Choosing Reliable Solutions for Delayed Task Execution in E‑commerce Systems

The author, a senior architect, examines the frequent need in e‑commerce and payment systems to automatically close orders after a timeout and critiques several ways to implement delayed tasks.

Typical Implementations

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

Using Redisson's DelayedQueue .

Flawed Solutions (Do Not Use)

Redis key‑expiration listeners.

RabbitMQ dead‑letter queues for delay.

Non‑persistent time wheels.

Redis Expiration Listening

According to the Redis official manual ( keyspace-notifications and timing-of-expired-events ), 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 removes expired keys via periodic offline scans and lazy checks on access; it does not guarantee immediate deletion at the exact expiration time, and notifications can be delayed by minutes. The key‑space notification uses a fire‑and‑forget strategy, so clients may miss events during disconnections.

Therefore, using Redis expiration listening for delayed tasks is unreliable and should be avoided.

RabbitMQ Dead Letter

A dead letter ( Dead Letter ) in RabbitMQ occurs when a message is negatively acknowledged with channel.basicNack and requeue=false , exceeds its TTL, or the queue length limit is reached.

Create a dead‑letter exchange.

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

Declare a queue bound to the dead‑letter exchange and consume from it.

Dead‑letter queues store messages that were not consumed normally, aiding troubleshooting and re‑delivery, but they also do not guarantee delivery timing; messages become dead letters only after the first one does.

RabbitMQ provides an official delayed‑message plugin ( rabbitmq-delayed-message-exchange ) which is the recommended way to handle delayed messages.

Time Wheel

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

Redisson DelayQueue

The redisson delayqueue builds a delayed queue on top of a Redis sorted set ( zset ). Elements are stored with a score equal to the delivery timestamp. The queue periodically runs zrangebyscore to fetch due messages and moves them to a ready list.

As long as Redis does not crash, the delay queue will not lose messages, making it a viable fallback when professional message queues are unavailable, provided a compensation mechanism is in place for Redis failures.

Conclusion

Prefer message queues with native delayed delivery such as rocketmq or pulsar .

If a professional queue is unavailable, consider Redis‑based solutions like redisson delayqueue , but design compensation for Redis crashes.

When neither is feasible, a time wheel can be used, though it requires additional protection mechanisms.

Never use Redis expiration listening for implementing delayed tasks.