How WeChat Handles Red Packet Grabs: Backend Secrets Revealed

When a user sends an N‑person red packet with a total amount M, the backend performs several steps.

1. Backend Operations for Sending Red Packets

A record is added to the database and stored in a key‑value store with an expiration time. A corresponding entry is also created in the cache (likely an internal KV database) to track the number of participants N.

2. Backend Operations for Grabbing Red Packets

The grab operation is handled entirely in the cache layer using an atomic decrement (implemented via CAS with version checks). When the count reaches zero, the packet is considered fully claimed, and further requests are blocked at the cache level. The CAS may experience conflicts; conflicted users are allowed to proceed to the “open” step, which explains why some users see the packet empty after opening.

The opening (settlement) step occurs in the database using a transaction that updates the number of claimed packets and the total amount, inserts a receipt record, and performs asynchronous accounting. The amount for each claim is a random value between 1 cent and twice the average of the remaining amount, with the maximum per packet capped at M*2/N (and never exceeding M). The system can handle up to 200,000 transactions per second in preparation, but actual peak is around 80,000 per second.

FAQ

Why can a user grab a packet but find it empty when opening? The atomic decrement is not a true atomic operation; it is a CAS provided by the cache layer that retries based on version numbers, leading to occasional conflicts.

What if cache or DB fails? A primary‑secondary setup with reconciliation ensures continuity.

Can the packet count be exhausted while the balance remains? No, the system performs a final "take‑all" operation and asynchronous reconciliation to guarantee consistency.

Why separate grab and open steps? This multi‑layer filtering reduces traffic and pressure on the backend. The grab step is lightweight and handled by cache, filtering out most requests before they reach the heavier database settlement.

Is there a strategy after grabbing a packet, such as re‑sending or withdrawing? Large amounts are prioritized for settlement.

Is the probability of each packet equal? It is not perfectly uniform; a simple heuristic algorithm is used.

Can the heuristic produce two "best luck" packets? Amounts may tie, but only the first claimant is considered the best.

Is the sender's money frozen? The amount is deducted in real time, not frozen.

Why calculate the amount in real time? Real‑time calculation is more efficient and avoids extra storage; the red packet record is short‑lived, so space consumption is minimal, and horizontal scaling can handle load spikes.