How WeChat’s Red Packet System Handles Millions of Claims in Real Time

The red‑packet grabbing feature became wildly popular after last year’s Spring Festival Gala, and many wonder how it works under the hood. Below is a technical breakdown of the backend implementation.

1. Sending Red Packet Backend Operations

When a user creates a red packet for N participants with a total amount of M yuan, the system records a new entry in the database and stores it in a key‑value store (CKV) with an expiration time. Simultaneously, a cache entry (likely an internal Tencent KV database) is created to track the number of participants N.

2. Grabbing Red Packet Backend Operations

Grabbing is divided into two stages: "grab" and "open". The grab step is performed entirely in the cache layer using an atomic decrement (implemented via a CAS loop that compares version numbers). When the counter reaches zero, the packet is considered fully claimed, and further grab requests are blocked at the cache level. Because the CAS is not a true hardware‑level atomic operation, occasional conflicts occur; conflicted users are allowed to proceed to the open step, which explains why some users may receive a "already opened" message after a successful grab.

The open step runs in the database. A transactional operation increments the claimed count and amount, inserts a claim record, and triggers asynchronous accounting. The amount for each claim is calculated as a random value between 1 cent and twice the average of the remaining amount, with the maximum per claim capped at M * 2 / N (and never exceeding M). After each claim, the remaining amount and count are updated. The payment system is provisioned for 200,000 transactions per second, though actual peak throughput is around 80,000 per second.

FAQ

Why can a user still see "already opened" after a successful grab? The cache‑level decrement uses a CAS loop, not a true atomic operation; conflicts may let a user proceed to the open step even when the packet is already exhausted.

What happens if the cache or database fails? A primary‑secondary replication with reconciliation ensures consistency.

Can the packet count reach zero while the balance remains? No. A final "take‑all" operation and asynchronous reconciliation guarantee that the amount and count are synchronized.

Why separate grab and open? The design creates multiple filtering layers to reduce load on the database. The grab step is a lightweight cache query that filters out the majority of traffic, leaving only a small fraction for the heavier database settlement.

Is there a strategy for large‑value packets? Large claims are prioritized for faster settlement.

Are the probabilities of each claim equal? Not perfectly; the algorithm uses a simple heuristic rather than a strict uniform distribution.

Can two users receive the same "best luck" amount? Yes, but only the first to claim is considered the best.

Is the sender’s money frozen? No, the amount is deducted in real time.

Why calculate the amount in real time? Real‑time calculation reduces storage overhead and improves efficiency, as each packet only needs a single record with a short expiration.