37. Design a News Feed
1
The interview prompt2
37.1 What do you ask first?3
37.2 How big is this, really?4
37.3 What are the doors?5
37.4 What do we store?6
37.5 What does the whole system look like?7
37.6 Fan-out on write or on read?8
37.7 How do you solve the celebrity problem?9
37.8 How does ranking work?10
37.9 How do the feed cache and pagination work?11
37.10 What would you say in the last five minutes?12
Score yourself13
Variations to practise14
Sources15
Code lab37. Design a News Feed
37.2 How big is this, really?
3 min read+10 XP
Step 2: Estimates (5 minutes)
Assume 8 bytes per post ID in a feed list, feeds cached for the 100 million most active users, 800 post IDs per cached feed, and that about half of followers are active in a given month.
| What | Working | Result |
|---|---|---|
| Posts a day | 200 million × 1 | 200 million (≈ 2,300 a second) |
| Feed loads a second | 200 million × 10 ÷ 86,400 | ≈ 23,000 average, ~70,000 at peak |
| Fan-out writes (push to every follower) | 200 million × 200 | 40 billion a day ≈ 463,000 a second |
| Skipping inactive followers | × 0.5 | 20 billion a day |
| One celebrity post at 500,000 writes a second | 50 million ÷ 500,000 | 100 seconds of fan-out for one post |
| Feed cache | 100 million × 800 × 8 bytes | ≈ 0.64 TB, sharded across a Redis cluster |
What the numbers say, out loud:
- "Reads dominate in count, but fan-out writes dominate in work: hundreds of thousands of small writes a second."
- "Push for normal accounts, pull for celebrities, and skip followers who haven't opened the app in a month."
- "Store IDs, not posts, in feeds: 8 bytes per entry instead of kilobytes."
Interviewer pushback:
- "Why not compute every feed on read?" → At 70,000 loads a second, each pulling recent posts from 200 accounts and merging, that's 14 million lookups a second at peak. Precomputing most of it on write is cheaper overall.
Memory code: "Count the fan-out writes before you count anything else."