A System Designer guide
News feed walkthrough
Estimate fanout work, keep posts authoritative and choose where to assemble feeds for ordinary accounts and celebrities.
This walkthrough uses the Social feed scenario. Try an attempt first if you want to make your own choices before reading a possible approach.
Requirements and scale
Every person opens the app and sees a feed of posts from the people they follow. Most people have a few hundred followers, but a few have millions, and when they post, millions of feeds must change. The feed must be fast and your own post must show up at once.
- Who uses it
- 50 million people a month
- Audience in plain numbers
- 50,000,000 people per month
- Normal peak
- ≈ 60,000 requests per second
- Request mix
- Read: 80%; Analytics event: 12%; Notification: 3%; Write: 2%; Search: 2%; Sign-in: 1%
- Speed for 99 of 100 requests
- Read: ≈ 350 ms; Write: ≈ 350 ms; Search: ≈ 500 ms; Sign-in: ≈ 1,000 ms
- Successful requests
- 99.9%
- Data safety
- At most 1 minute of writes may be lost.
- Monthly budget
- ≈ $170,000
- Data at rest
- ≈ 60 TB
- Where users are
- North America: 40%; Europe: 30%; Asia Pacific: 30%
- Home region
- North America
- Waiting deadlines
- Read: 900 seconds; Analytics event: 3,600 seconds; Notification: 900 seconds; Write: 3,600 seconds; Search: 900 seconds; Sign-in: 900 seconds
- Fresh reads
- People must see their own changes. At most 0.1% of reads may be stale in the model.
- Personal reads
- 60% of reads are private; a shared public copy cannot answer them.
≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.
- About 20 million posts are made per day (approx.).
- A post is about 1 KB. Media is handled by a different system.
- Notification speed measures provider acceptance. Device receipt is outside this traffic model; check expiry, provider outcome and retries in the correctness trace before claiming delivery guarantees.
Estimates to work through
- Feed loads per second at peak
- ≈ 48,000 req/s. 60,000 x 0.8 (approx.)
- Posts per second on average
- ≈ 230 posts/s. 20 million per day / 86,400 (approx.)
- Feed updates per second with fanout on write
- ≈ 46,000 writes/s. 230 posts/s x 200 followers (approx.)
Choose the unit of work
A post is one record, but it can create many feed updates. Start by separating post creation, follower delivery and reading a feed. The exercise begins with time order rather than ranking. The author must see their own post immediately; other feeds can be a few seconds behind.
Use the scenario’s Numbers values below as separate estimates with stated assumptions. Its clarification describes a rough read-to-post ratio, while its scored request mix also includes events, notifications, search and login. Use that scored mix when sizing request paths rather than treating the rough ratio as the entire workload.
A design that holds
Save the post as the source of truth. For ordinary accounts, place post identifiers into followers’ prepared feeds using queued workers. Feed reads then fetch a short list rather than scanning every followed account. Make workers restartable: a retry must not insert the same feed entry twice.
Treat very large accounts differently. Instead of writing into every follower’s feed on each celebrity post, fetch those posts when a person opens their feed and merge them with prepared entries. Include the author’s own new post directly so delayed background fanout does not hide it from its creator.
The trade-offs
Preparing feeds makes frequent reads cheap but multiplies writes by follower count. Assembling everything at read time saves those writes but moves work into the response path. A hybrid has more policy and operational complexity, so explain the measurement that justifies its threshold.
A cached feed is a shortcut, not the only copy of the post. Rebuilding it should be possible from durable posts and follow relationships. Separate private feed contents from public media that many people can share at the edge.
What breaks it
A celebrity post can grow the fanout backlog faster than workers drain it. A popular item can overload one cache partition. A cold cache can send many reads back to storage. Each is a different failure: adding shards may not split one hot key, and adding workers may only overload the destination faster.
Use One post, millions of feeds and When one item is popular before trying Social feed. Predict where work moves when you switch a large account from push to pull, then compare both write pressure and read latency.
The day that tests the design
Consumer traffic, busiest in the evening. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.
12:00 · Celebrity post
A popular account posts, multiplying the work needed to update follower feeds.
Work multiplier: 25. Duration: ≈ 900 seconds.
17:30 · Hot key
One item gets a huge share of traffic: a celebrity profile, one product, one merchant.
Affected share: 30%. Duration: ≈ 3,600 seconds.
08:15 · Cache stampede
The cache empties (restart, purge, mass expiry) and every request rushes to the database at once.
Recovery window: ≈ 300 seconds.
Play this problem. Keep one baseline, predict a change and compare the next full day. The in-game editorial has calibrated reference designs after you finish a traffic day.