How WeChat Handled 100 Billion Red Packet Requests During the Spring Festival Gala

During the Spring Festival Gala, WeChat's red‑packet system processed billions of shake requests, delivering cash greetings and red packets to users under extreme traffic conditions.

V0.1 Prototype System

The prototype handled a shake request from the client, routed it to a shake service to determine the result (cash greeting or red packet), fetched logo and background resources, and then processed the red‑packet opening through the red‑packet system, payment system, and transfer to the user. Split red packets could be shared further. The overall flow was categorized into resource, information, business, and fund flows, with emphasis on resource and information flows.

1. Challenges

Massive request volume was anticipated: 7 hundred million viewers, with peak traffic estimated at 10 million QPS, surpassing peaks of train ticket booking (120 k QPS) and WeChat messaging (330 k QPS). Additional challenges included late finalization of activity details, live‑broadcast timing changes, a one‑time custom system, high public visibility, and lack of prior experience.

2. Problems in Prototype

Bandwidth demand was projected at 3000 Pb/s, causing download latency after a shake. External network quality needed to support roughly 3.5 billion concurrent users, and the system had to handle 10 million QPS for both the shake service and backend, a scale beyond typical distributed systems.

3. Solutions

Static resources were pre‑pushed to clients; 65 resources totaling 3.7 PB were distributed, with a peak of 1 Tb/s, reducing download delays. Eighteen access clusters across Shanghai and Shenzhen, comprising 638 servers, supported up to 1.46 billion concurrent connections.

The shake service was merged into the access layer, splitting logic and using an Agent for dynamic updates. Overload protection employed client‑side throttling and backend rejection to limit request rates.

Red‑packet issuance used seed files distributed to each access server, controlling issuance rate, preventing duplicate claims, and limiting per‑user claims (e.g., three per user). An Agent checked client data to mitigate malicious behavior, and big‑data analysis identified abnormal accounts.

Live interaction with the gala involved multiple deployment sites, three‑step configuration synchronization, countdown adjustments, real‑time calibration, and fallback mechanisms to handle unexpected changes.

V0.5 Test Version

With a confidence index of 50 %, the focus shifted to ensuring a smooth red‑packet opening and sharing experience, using an “iron triangle” of user action, backend logic, and reliability.

V0.8 Preview Version

Confidence rose to 70 % by emphasizing comprehensive load testing, code review, internal rehearsals, online pre‑heat, and post‑mortem analysis.

V1.0 Official Version

The final system, deployed on February 18, achieved a confidence index of 80 % and processed 110 billion shakes, with a peak of 8.1 billion shakes per minute (approximately 14 million QPS).