How WeChat Scaled Red Packets for 80 Billion Transactions: Architecture Secrets

Compared with traditional red packets, the modern digital "red packet" has become a major Spring Festival highlight, with 80.8 billion WeChat red packets sent on New Year's Eve and a peak of 409 k packets per second.

Architecture Overview

WeChat users connect via two domestic access points—Shenzhen (south) and Shanghai (north). The red‑packet service separates order data (transactional) from user data (display) and deploys independent north‑south systems.

North‑South Distribution

Orders are tagged with a north or south identifier, routing requests to the corresponding data‑center. Four scenarios arise:

Shenzhen user sends and Shenzhen user grabs – local processing.

Shenzhen user sends, Shanghai user grabs – cross‑city routing to Shenzhen.

Shanghai user sends and grabs – local processing.

Shanghai user sends, Shenzhen user grabs – cross‑city routing to Shanghai.

This design balances traffic and reduces system risk.

User Data Write‑Read Strategy

User data is written asynchronously to Shenzhen via MQ, while reads are served from cache, allowing low‑latency access without heavy DB load.

Flexible Traffic Control

The system can force all traffic to a single region (e.g., Shenzhen) at the access layer, providing rapid disaster‑recovery capacity and second‑level capacity adjustments based on real‑time monitoring.

DB Failure Traffic Shift

When a database fails, traffic is redirected to the healthy region, ensuring continuous service.

Pre‑order Cache

Before payment, orders are stored in cache with atomic increment to generate order IDs, reducing DB waste and handling conversion loss.

Asynchronous Settlement

Red‑packet settlement is decoupled: a voucher is recorded in DB, then an async queue handles the actual account credit. Failures are compensated via a retry queue, guaranteeing eventual consistency.

Dual‑Layer Cache for Operations

All reads are served from a two‑level cache (in‑memory + CKV). Writes sync to cache and DB, with occasional async compensation; periodic reconciliation ensures data integrity.

High Concurrency Handling

To manage massive simultaneous grabs, requests are routed based on red‑packet order hash, ensuring sticky placement to a single logical machine and DB.

Local memcache counts concurrent grabs per order, limiting DB access. Multi‑level flow control caps traffic at the send, grab, and open stages, while DB sharding (order hash + daily table rotation) separates hot and cold data, reducing lock contention.

Red‑Packet Algorithm

The algorithm computes a lower bound (minimum amount per grab) and an upper bound (maximum per grab, capped at twice the remaining average). A random number modulo the upper bound determines the actual amount, ensuring fairness and preventing extreme variance.

Graceful Degradation

Cache failure during order creation falls back to DB with ID generator.

Cache failure during grab falls back to DB with rate‑limiting.

Settlement can switch between real‑time transfer for large packets and async queue for small ones.

User list queries are limited to two screens when cache is unavailable.

The revised system successfully handled the 2016 Spring Festival peak without service disruption.