Design and High‑Availability Architecture of the WeChat Red Packet Storage Layer

WeChat Red Packet originated from an internal employee tradition and quickly grew into a phenomenon, reaching over 100,000 transactions per second and nearly one billion orders per day by 2016. The system handles small‑amount fund flows through three steps—sending, grabbing, and opening—requiring strong transactional guarantees, which led to the choice of MySQL as the primary storage engine.

Front‑end traffic control is essential to prevent backend overload. Techniques include stateless CGI, static resource offloading via CDN, asynchronous business pipelines, overload protection with layered rate‑limiting, multi‑level read caching, and order‑write caching to filter unnecessary requests before they reach the database.

High‑availability storage design addresses massive growth by combining several strategies:

Read/write separation : write traffic stays on the master, while latency‑tolerant reads are served from replicas, increasing capacity.

Horizontal partitioning (sharding) : data is split across multiple databases/tables based on key dimensions, enabling parallel scaling and reducing single‑node load.

Vertical partitioning : core fields remain in the primary database, while large, non‑critical fields (e.g., nicknames, messages) are moved to separate machines or NoSQL stores.

Space‑for‑time trade‑off : tables are organized by order or user attributes to simplify queries and allow selective redundancy.

Lock optimization : transaction scope is minimized and requests for the same order are serialized in the application layer to avoid MySQL row‑level deadlocks.

Hot‑cold separation : frequently accessed data stays on high‑performance SSDs, while older data is migrated to cheaper cold storage, preventing table bloat.

To further improve resilience, a dual‑active data‑center architecture and multi‑active cross‑region deployment are employed. Users are routed to the nearest data center, data is kept independent across regions to avoid real‑time synchronization latency, and disaster recovery mechanisms allow traffic failover between cities (e.g., Shenzhen to Shanghai).

The system also adopts loss‑tolerant services and graceful degradation. Core functions (grabbing and opening red packets) are prioritized for availability, while non‑critical features may be degraded under load, ensuring eventual consistency of financial data.

In conclusion, the article outlines the design principles of the WeChat Red Packet storage layer, emphasizing that early preparation for massive traffic is crucial for the success of any rapidly growing internet service.