Implementing Precise Order Cancellation: Pitfalls of Redis Expiration and Better Alternatives

Introduction

In e‑commerce and payment systems, orders that are not paid within a certain time need to be automatically closed, and many platforms achieve sub‑second accuracy. This article examines common implementations and why some are unsuitable.

Common Approaches

Using the delayed‑delivery features of message queues such as rocketmq , rabbitmq , pulsar .

Using Redisson's DelayedQueue built on Redis.

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

Redis key‑expiration listeners.

RabbitMQ dead‑letter queues.

Non‑persistent time wheels.

Redis Expiration Listener

The Redis manual states that expired events are generated only when the server actually deletes the key, not when the TTL reaches zero. Redis removes expired keys via periodic scans or lazy checks on access, so notifications can be delayed by minutes and are sent on a fire‑and‑forget basis, meaning clients can miss events during disconnections. Therefore, this method is unreliable for precise timing.

RabbitMQ Dead‑Letter

A dead‑letter is created when a message is negatively acknowledged with channel.basicNack (requeue = false), exceeds its TTL, or the queue is full. Configuring a dead‑letter exchange and routing key directs such messages to a dead‑letter queue, but delivery time is not guaranteed. RabbitMQ provides an official delayed‑message plugin ( rabbitmq-delayed-message-exchange ) for proper delayed delivery.

Using Redis expiration listeners or 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 data structure for timers, but most implementations are in‑memory only. If the process crashes, all scheduled tasks are lost, so it should be used with caution.

Redisson DelayQueue

The redisson delayqueue leverages a Redis sorted set ( zset ) where each element’s score is the delivery timestamp. A background job calls zrangebyscore to move due items to a ready queue. This approach preserves messages as long as Redis remains alive and can be combined with database scans for compensation.

Conclusion

Prefer message queues with built‑in delayed delivery such as rocketmq or pulsar .

If a professional queue is unavailable, consider redisson delayqueue but add protection for Redis failures.

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

Never use Redis expiration listeners for delayed tasks.