How WeChat Processed 1.4 B Red Packets per Second: Architecture & Key Lessons

Community Introduction: After a year of preparation in 2014, the 2015 WeChat Red Packet volume reached a historic peak—1400 million requests per second, 8.1 billion per minute, and 1.01 billion total sends, with the system running smoothly. Below is a technical deep‑dive into the architecture behind this achievement.

Core Functions & Goals

The Red Packet workflow consists of four logical steps: shake, send, grab, and open. The goals are:

Shake: smooth experience

Grab: ultra‑fast response

Open: satisfying experience

Share: reliable distribution

System Challenges

Complex Chinese carrier networks and congestion during the Spring Festival.

Avoiding service avalanche during peak shaking periods.

Providing flexible services with limited resources.

Designing lossy services.

Constructing a set model.

Handling concurrent grabs.

Ensuring data consistency.

System Architecture Diagram

Cross‑Region Network Solution

WeChat clients are globally distributed, allowing user data to be accessed near the access point, but the Red Packet business logic is not fully distributed, requiring strong consistency for the data layer. To minimize latency, the call chain is optimized at the access layer, reducing network overhead and boosting throughput. Physical implementation also includes backup routing to quickly switch networks when a dedicated line fails.

How to Build a Lossy Service

A lossy service deliberately sacrifices some data consistency and completeness to guarantee core functionality for the majority of users. After a short window, consistency is restored. This strategy enables the system to prioritize critical actions (shake, open, share) and degrade gracefully when related services encounter issues, preventing cascade failures.

Flexible Service: Enhancing User Experience

Under the lossy‑service philosophy, the system adapts to user scenarios, allocating resources to ensure key data returns quickly while less critical operations (e.g., avatar update, fund transfer) are retried asynchronously. This approach keeps users informed of successful grabs without forcing them to wait for ancillary tasks.

Constructing the Set Model

The Set module acts as a container that standardizes, modularizes, and scales services. For Red Packets, orders are sticky to a specific set (often within the same IDC), reducing inter‑set latency. If a set’s database fails, new orders bypass that set, and the system masks the faulty set while preserving overall availability.

Solving Concurrent Grab Issues

High‑concurrency grabs can overwhelm traditional MySQL locking. By routing all requests for a given Red Packet to the same set and caching its status, the system applies rate limiting and consistent hashing to serialize access at the DAO layer, turning a high‑contention operation into a near‑serial one with dramatically improved throughput.

Achieving Data Consistency

Referencing the CAP theorem, the system prioritizes availability and partition tolerance while aiming for eventual consistency. Data is stored in three replicas (N=3). Reads can be satisfied from any replica (R=1), while writes are performed synchronously to two replicas and asynchronously to the third (W=2), satisfying the inequality R + W ≤ N. User data updates are handled asynchronously via a message center with retry mechanisms, complemented by near‑real‑time reconciliation to ensure final consistency.

Source: Architecture Talk