Implementing Order Auto‑Cancellation with Redis Pub/Sub to Avoid Polling

In many transaction scenarios an order has a payment deadline, after which the order should be automatically cancelled; this article outlines how to implement that functionality.

01 – Timed polling is not advisable

Directly polling the database on a schedule is a common first thought, but it has two major drawbacks: (1) the polling interval cannot guarantee precise cancellation times because order submission times are random, leading to up to a minute of error if polling every minute, and (2) frequent polling consumes excessive server and database resources, making it wasteful even if a minute‑level error is acceptable. Polling can be kept as a low‑frequency fallback for extreme cases, but should not be the primary method.

02 – Passive cancellation

Passive cancellation simply checks the order’s timeout when a user queries the order information and cancels it if it has expired. This approach depends on the user’s query; if the user never checks the order, the cancellation never occurs.

03 – Active cancellation

To avoid polling and achieve proactive cancellation, a message‑queue‑like mechanism such as Redis Pub/Sub can be used. After an order is successfully submitted (but not yet paid), the application publishes a delayed message to a custom Redis channel; a separate cancellation service subscribes to the same channel and, upon receiving the message, executes the cancellation logic. This naturally decouples the services.

In Node.js, the ioredis library is recommended for interacting with Redis. While professional message‑queue solutions (MQ) offer higher stability and reliability, they also bring higher cost; if the use case does not demand such robustness, Redis Pub/Sub is a simpler, cost‑effective choice.

Combining these methods as needed provides a reliable solution for order auto‑cancellation. End of article.