How Weibo Handles 100k QPS During Viral Peaks: Architectural Secrets

Step 1: Quantify the load

Assuming 1 billion registered users and a 20% daily active rate, Weibo processes roughly 200 million posts per day. Each post (140 characters plus metadata) consumes about 500 bytes, resulting in ~100 GB of text daily; media adds another 60 TB. With each active user refreshing twice and each refresh issuing ten queries, the system sees 4 billion queries per day, or an average of 50 k QPS. Peak traffic is estimated at twice that, requiring the system to sustain 100 k QPS. At 20 posts per response, the bandwidth demand reaches 4.8 Tb/s.

Step 2: Push‑pull hybrid for feed delivery

The core problem is delivering a newly posted tweet to a user’s followers as quickly as possible. Two classic approaches exist:

Push model: Immediately write the tweet to every follower’s timeline. This yields instant reads but can cause massive write amplification (e.g., a celebrity with 50 million followers would generate 50 million writes at once).

Pull model: Store the tweet once and fetch it on each follower’s refresh. Writes are cheap, but a user following 2 000 accounts would trigger 2 000 reads per refresh, overwhelming the database.

The solution combines both: normal users use the push model to guarantee fast reads, while “big V” users push only to currently online followers; offline followers receive the tweet via the pull model when they log in. This hybrid minimizes write cost while preserving low‑latency reads, exploiting the fact that read traffic typically exceeds write traffic by 300–500×.

Step 3: Four‑tier cache funnel

Directly sending 100 k QPS to the database is infeasible, so Weibo adopts a layered “funnel” cache:

CDN layer: Static assets (images, videos) are served by edge nodes; >90% of such traffic is satisfied without hitting origin, absorbing most of the 4.8 Tb/s bandwidth.

Local in‑process cache: Application servers keep the last 48 hours of posts from high‑profile users in memory, allowing hot‑spot reads without even contacting Redis.

Redis distributed cache: Recent posts from the past seven days (~700 GB) are cached with a time‑based eviction policy rather than LRU, preserving timeline completeness and avoiding cache fragmentation.

MySQL sharded storage: Only cache‑misses fall through to the database, reducing effective QPS to a few thousand.

Step 4: Database sharding and write throttling

During peak periods, write volume reaches 4 600 tweets per second. A single node cannot handle this, so Weibo shards the MySQL cluster. Two sharding strategies are considered:

Shard by tweet ID – evenly distributes writes but makes retrieving a user’s timeline expensive because it requires scanning all shards.

Shard by user ID – concentrates a celebrity’s data on one shard, but the earlier cache funnel mitigates the hotspot.

The final design shards by user‑ID hash, couples it with a message queue that buffers write bursts. Consumers write to the database at a controlled rate, preventing sudden spikes from overwhelming storage. Additional safeguards include read‑write separation, rate‑limiting, degradation, and circuit‑breaker protection, which together keep the database stable under storm conditions.

Reusable feed‑system template

Combining the four steps yields a repeatable architecture for any high‑throughput information‑flow product:

Quantify QPS, storage, and bandwidth requirements.

Select a push‑pull hybrid distribution, treating high‑profile users specially.

Build a multi‑level cache funnel (CDN → local → Redis → DB).

Apply user‑ID sharding, message‑queue‑based write smoothing, read‑write separation, and protective throttling.

This pattern also fits WeChat Moments, Douyin’s feed, and Toutiao’s recommendation stream; the only differences lie in the content type being pushed.

The essence of architecture is trade‑off: push saves read latency at the cost of write volume, pull saves write volume at the cost of read latency, and the hybrid finds a balanced sweet spot. Caching is indispensable, and sharding becomes mandatory when data scales to billions of rows.