Why Using Redis Expiration Listener for Order Cancellation Is a Bad Idea

Introduction

In e‑commerce and payment systems, orders that are not paid must be closed after a precise timeout (often within a 1‑second error margin). The article lists typical ways to implement this delayed closure.

Common Approaches

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

Use Redisson’s DelayedQueue built on Redis.

It then warns that several widely‑circulated solutions have fatal flaws and should not be used for delayed tasks.

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 expires keys via a background scan and lazy deletion on access, so the server never guarantees immediate deletion or notification. Expiration notifications can be delayed by minutes, and the key‑space notification uses a fire‑and‑forget strategy; a client that disconnects will miss all events sent during the outage. Therefore, using Redis expiration listeners for precise timing is unreliable and should be avoided.

RabbitMQ Dead Letter

A dead‑letter is created when a message is negatively acknowledged without requeue, exceeds its TTL, or the queue exceeds its max length. When a dead‑letter exchange is configured, such messages are routed to a dead‑letter queue. The article outlines the setup steps:

Create a dead‑letter exchange.

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

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

Dead‑letter queues store messages that were not consumed normally, but they also do not guarantee delivery timing; later messages may expire before the first dead‑letter is processed. The author recommends using RabbitMQ’s official delayed‑message‑exchange plugin for reliable delayed messaging.

Time Wheel

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

Redisson DelayQueue

Redisson’s delay queue is built on a Redis zset. It stores tasks in an ordered set where the score is the delivery timestamp. A background scan using zrangebyscore moves due tasks to a ready list. As long as Redis does not crash, messages are not lost. The article suggests combining this with a database‑scan compensation mechanism to guard against Redis failures.

Conclusion

Prefer message queues with native delayed delivery (e.g., RocketMQ, Pulsar).

If a professional queue is unavailable, use Redisson delay queue but add compensation for Redis crashes.

If Redisson is unsuitable, a time wheel can be used, but ensure frequent persistence and protective measures.

Never use Redis expiration listeners for delayed tasks.