Design a News Feed
Facebook / Instagram feed — aggregate posts from people you follow, ranked, at billions-of-reads scale.
Overview
A news feed shows a personalized, ranked stream of posts from accounts a user follows. The central tension is fan-out: do you build feeds when content is written (push) or when it's read (pull)? The answer — a hybrid keyed on the celebrity problem — is the whole interview.
Requirements
Functional
- A user's feed shows recent posts from accounts they follow.
- Posts can contain text, images, and video.
- Feed is ranked (relevance), not strictly chronological.
- New posts appear without a full refresh; support pagination/infinite scroll.
Non-functional
- Feed load latency < 200 ms — this is the app's front door.
- Extremely read-heavy; eventual consistency is acceptable (a post can appear seconds late).
- Scales to hundreds of millions of DAU and celebrity accounts with 100M+ followers.
Back-of-the-envelope
The numbers that justify the architecture.
| DAU | 300M | |
| Feed reads / day | ~1.5B | 5 refreshes/user/day |
| Posts / day | ~100M | |
| Feed reads / sec (peak) | ~50K | justifies pre-computed timelines |
Reference architecture
A write path that fans posts out into per-user timeline caches, a read path that merges cached timelines, and a ranking service on top.
Deep dives
Fan-out on write vs on read
Fan-out on write (push): when a user posts, immediately insert the post id into every follower's precomputed timeline (a Redis list). Reads are then dirt cheap — just fetch your list. But a celebrity with 100M followers triggers 100M writes per post (a 'fan-out storm'), and inactive followers get feeds computed for nothing.
Fan-out on read (pull): store posts by author; at read time, gather the latest posts from everyone you follow and merge. Cheap writes, expensive reads, and terrible for users following thousands of accounts.
The hybrid model (what real systems do)
Use push for the common case and pull for celebrities. Most users' posts fan out on write. For accounts above a follower threshold, do not fan out; instead, at read time, merge the user's precomputed timeline (from normal follows) with a live fetch of the few celebrities they follow. This bounds the write amplification while keeping reads fast. This 'celebrity problem' answer is the single most important idea in the design.
Ranking and freshness
Chronological is a baseline; production feeds rank by predicted engagement (a model scoring recency, affinity, media type, past interaction). Precompute candidate post ids in the timeline cache, then hydrate and score the top N at read time. Keep the timeline cache bounded (e.g., last 800 ids) and page beyond it from the posts DB.
Media handling
Never push image/video bytes through the feed. Upload media to blob storage, serve via CDN, and carry only URLs + metadata in the timeline. Generate multiple resolutions on upload for adaptive delivery.
Key trade-offs
For each decision: the two options, and when to pick which.
Bottlenecks & follow-ups
Where it breaks under load — and what an interviewer will probe.
- ▲Celebrity fan-out storm → don't fan out above a follower threshold; merge on read.
- ▲Timeline cache memory → bound list length, evict inactive users.
- ▲Hot ranking service → precompute candidates, score only top N.
What a strong answer sounds like
- ✓Get to the hybrid fan-out answer fast — it's what the question is really testing.
- ✓Separate the write path (fan-out) from the read path (merge+rank) explicitly on the whiteboard.
- ✓Mention media goes to CDN, not through the feed — a common omission.