How to Build a High‑Throughput Coupon Push System with a Redis‑Based Scheduled Task Cluster

Recently I developed a coupon‑center project that relies heavily on Redis. The core feature is a "coupon subscription push" where users subscribe to a reminder that is sent one minute before the coupon becomes claimable.

The business scenario involves over 60 million registered users; a popular coupon can attract more than 200 000 subscription pushes that must be delivered within a minute, creating two main challenges: real‑time delivery and massive volume.

Why Traditional Approaches Fail

Solution 1: MQ delayed delivery – MQ supports coarse‑grained delays (seconds to minutes) and cannot guarantee precise timing; handling cancellations and deduplication is also problematic.

Solution 2: Simple cron jobs – Periodic tasks that scan the database are easy to implement but suffer from performance bottlenecks, poor timeliness, and single‑point failures.

Redis‑Based Scheduled Task Cluster

To overcome these issues we redesign the cron job into a distributed, second‑level task cluster powered by Redis:

High timeliness – tasks are triggered at second granularity.

High throughput – adding more servers linearly increases capacity.

No single‑point failure – the cluster continues as long as the Redis cluster and at least one server are alive.

The architecture stores subscription records in a Redis SortedSet where the score is the reminder timestamp. Each business server runs a 1‑second timer, fetches due records from its assigned queue, and pushes notifications via the message center.

Key design points:

Performance scales with the number of servers; each server processes its own queue.

Timeliness reaches second‑level because the SortedSet naturally orders by timestamp.

Failure tolerance is achieved by avoiding a single coordinator; only a Redis outage would halt the system.

We hash user_id to a configurable number of queues (typically matching the number of processing servers) to balance load and allow merging of near‑identical push times.

The queue count and batch size are dynamically configurable via Alibaba’s Diamond service, enabling the cluster to adapt to traffic spikes such as large promotions.

Load balancing is implemented with a Redis atomic increment key combined with modulo‑queue logic, preventing multiple servers from competing for the same queue.

Throughput Estimation

With 10 servers each pulling 2 000 records per batch, the cluster can push 20 000 notifications per second. Adding MQ for asynchronous delivery adds roughly 0.5 s overhead, meaning 200 000 pushes complete within a few seconds.

Future Enhancements

Add monitoring to detect backlog.

Provide a visual management console.

Implement priority scheduling for urgent pushes.

Introduce resource‑aware throttling when server capacity is limited.

The system is already in production and running smoothly.