Design and Implementation of Red Packet Calculation and Distribution System for Spring Festival Activity

The article describes the red packet calculation and distribution challenges in a Spring Festival “Talent Lucky Bag” activity, where users can receive multiple red packets, share for doubling, and receive lucky packets, requiring accurate and timely computation despite continuous user actions.

To handle the static budget and dynamic packet states, the system performs an offline batch calculation (T1‑T2) shortly before activity end, capturing a snapshot of all users’ packet states, with results ready in about ten minutes and allowing rapid recomputation if needed.

During the offline window, user actions are saved via delayed MQ messages; a real‑time calculation phase (T2‑T3) reprocesses those users to avoid loss, triggered by packet receipt or doubling events.

Because there is no gap between activity end and awarding, a compensation verification task at T3 checks for any computation loss and corrects it before users start manual awarding.

Manual awarding occurs from T3 to T4, followed by automatic awarding from T4 to T5, ensuring every user’s packet is settled.

For scalability, a distributed task framework splits work by userId using sharding (10 databases, 1000 tables) and assigns shards to container‑cloud cluster machines, supporting dynamic scaling, checkpoint‑based fault tolerance, idempotent processing, and synchronization of multi‑level caches (DB, Redis).

Stability measures include retry mechanisms for external dependencies (Kconf, risk control, main‑hall mem/DB/Redis), fallback degradation, and MQ‑based retries for task failures.

The awarding subsystem similarly uses asynchronous MQ calls to an incentive middleware, rate‑limiting consumers, and automatic retry with fallback to manual re‑execution.

Post‑implementation statistics show zero loss, zero errors, and zero user complaints for both calculation and awarding phases.