Implementing Delayed Tasks: Four Common Approaches (DB Polling, DelayQueue, Redis Zset, RabbitMQ TTL+DLX)

Business Scenario

When purchasing a train ticket or ordering food delivery, after placing the order the user is redirected to a payment page that includes a countdown timer; if payment is not completed within the allotted time the order is automatically cancelled. This is a typical delayed‑task scenario where the key requirement is to trigger order cancellation immediately when the timeout expires.

Polling the DB with a scheduled task

After an order is created, a record is stored in the database containing order ID, user ID, creation time, details, status, etc. Assuming a timeout of 600 seconds, a background scheduled job runs at a fixed interval, scans the table for orders whose createTime is older than now‑600, and cancels them, e.g.: select * from order where createTime <= now()-600 This method is simple but has drawbacks: if the job runs every second it scans the whole table each second, consuming DB resources; if it runs every minute the cancellation may be delayed (e.g., an order timed out at 600 s might be cancelled at 660 s).

Java DelayQueue

JDK’s DelayQueue is an unbounded blocking queue that only allows elements to be taken after their delay has expired. When an order is created, the order ID and related information are also submitted to a DelayQueue, which orders elements by their timeout. A dedicated thread continuously takes elements from the queue and performs order cancellation.

The main drawback is that the timeout information is not persisted; if the service restarts, the elements in the DelayQueue are lost.

Redis Zset

A Redis sorted set (zset) named "delayOrders" can be used where each member is an order ID and its score is the expiration timestamp. The system repeatedly retrieves the member with the smallest score, checks whether it has expired, and if so removes it from the set and cancels the order; otherwise it proceeds to the next iteration.

RabbitMQ TTL + DLX

RabbitMQ allows setting a message TTL (time‑to‑live). When a message expires it can be routed to a dead‑letter exchange (DLX) and then to a dead‑letter queue for re‑consumption, enabling delayed processing.

Below are diagrams comparing the four solutions.