1Context and scope
The news feed is the most-loaded page in the product: every open retrieves hundreds of candidate posts for the viewer, scores them with a model, and returns the top ones. Posts are rarer and are pushed into followers’ timelines asynchronously. This design covers the feed and post paths with the social graph behind a read-through cache, based on Meta’s published papers on TAO and feed ranking, scaled to a browser run.
2Goals and non-goals
Goals
- 5,000 requests a second: 85% feed loads, 15% posts.
- Success at least 99%, p99 at most 500 ms, Apdex at least 0.90.
- Posts reach timelines through Kafka with nothing lost.
Non-goals
- Ads ranking and auction.
- Comments, reactions and messaging.
- Multi-region replication of the graph.
3Capacity estimate
| Quantity | Value | How |
|---|---|---|
| Feed loads | ≈ 4,250/s | 85% of 5,000 |
| Feed cache | 64 GB, 50M entries, 5 min TTL, 1M ops/s | short TTL keeps feeds fresh; popularity skew keeps the hit rate high |
| Ranker | 2,048 slots, 128 vCPU, 4 ms CPU | 4,250 × 4 ms ≈ 17 vCPU busy; 4,250 × 20 ms ≈ 85 slots |
| Social graph calls | ≈ 1,275/s | 30% of feed loads need a graph lookup the cache did not cover |
| Posts | ≈ 750/s | one MySQL write and one Kafka event each |
| Fan-out | 256 workers at ≈ 8 ms | about 32,000 timeline writes a second of headroom over 64 partitions |
The rest of the doc
The design · Key concepts · Alternatives considered · Failure modes and fixes · Try it in the lab · Check yourself · Further reading
Unlock the Facebook news feed design doc
Every component and why it is there, the capacity numbers behind it, what breaks when you push it and how to fix it, and the same system open in the lab to break and fix yourself. Paid once, on your account.