A news feed is the list of stories on your home page that keeps updating — posts, photos, videos and links from the people you follow. "Design a news feed system" is one of the most common interview questions, and the same answer fits Facebook News Feed, Instagram and the Twitter timeline. The whole design comes down to one choice: when do you build each user's feed — the moment someone posts, or the moment someone opens the app?
The animation on the right shows the two fanout models side by side. ("Fanout" just means copying a new post out to all the followers who should see it.) First a normal user posts, and the fanout service pushes that post into every follower's feed — this is fanout on write. Then a celebrity with 50 million followers posts. Pushing to that many people at once would crush the system, so her followers pull her posts when they open the app instead (the hybrid model). Finally, reading a feed hydrates the stored ids into full, ready-to-show posts.
Step 1: Ask questions and estimate the scale
Before you design anything, agree on what you are building. A quick back-and-forth with the interviewer usually settles on this:
- Platform: both web and mobile.
- Main features: a user can post something, and see her friends' posts on the feed page.
- Order: newest first (keep it simple — no fancy ranking).
- Friend limit: up to 5,000 friends per user.
- Traffic: 10 million daily users.
- Media: posts can have images and videos, not just text.
Back-of-the-envelope math
Even when the interviewer gives you the numbers, use them. Out loud, turn "10M daily users" into a write rate and a read rate. Those two numbers are what prove you need a cache and what drives the push-vs-pull choice. Sizing before designing is the strongest signal you can send about your process.
Here QPS means "queries per second" — how many requests hit the system each second.
Daily users = 10,000,000
Say each user posts ~2 times a day:
Write QPS = 10M x 2 / 86,400 ≈ 230 posts/sec (at peak ~2-3x → ~700/sec)
People read far more than they post:
Read-heavy → a cache in front of the feed is a must
The number to watch is fanout cost:
friends per user = up to 5,000
one normal post → up to 5,000 feed writes
one celebrity post → up to tens of millions of writes ← the real problem
The point: a post from a normal user is cheap to copy out, but a post from someone with a huge following can mean tens of millions of writes. That gap is what the whole deep-dive is about.
Step 2: The two API calls
The feed APIs use HTTP. Two of them matter most:
-
Post something —
POST /v1/me/feedParams: content : the text of the post auth_token : proves who is making the request -
Get the feed —
GET /v1/me/feedParams: auth_token : proves who is making the request
Step 3: The high-level design
The system has two flows: publishing a post and building a feed to read.
| Component | What it does |
|---|---|
| Load balancer | Spreads traffic across the web servers |
| Web servers | Check login + apply rate limits, then pass the request to internal services |
| Post service | Saves the post in the database and cache |
| Fanout service | Delivers the new post to friends' feeds |
| Notification service | Tells friends there is new content |
| Newsfeed service | Reads the feed's post ids from cache and fills in the details |
| Newsfeed cache | Holds the post ids for each user's feed |
Point out that web servers do more than just pass requests along: they check the login (only valid
auth_tokens can post) and rate-limit (cap how often someone can post, to block spam). Naming
these extra concerns without being asked reads as senior.
Step 4: Deep dive — the fanout service
Fanout
Delivering a new post to all of a user's friends or followers. There are two ways to do it: fanout on write (push) and fanout on read (pull). The best answer is a mix of both.
Fanout on write (the push model)
Here the feed is built ahead of time, when someone posts. The moment a user posts, the new post id is copied straight into every follower's feed cache.
| Fanout on write (push) | Fanout on read (pull) | |
|---|---|---|
| When the feed is built | When you post | When you read (on demand) |
| Reading the feed | Fast — it's already built | Slow — built fresh each time |
| Cost for users with many followers | Bad — the "hotkey" problem, millions of writes per post | Good — nothing gets pushed |
| Cost for users who rarely log in | Wasteful — you build feeds nobody reads | Good — work only happens on read |
The hybrid model (what to actually build)
Fast reads matter a lot, so use push for most users. But for celebrities — people with a huge number of followers — let their followers pull the posts on demand when they read. This avoids the hotkey problem of pushing one post to tens of millions of caches. (A "hotkey" is one piece of data that suddenly gets a flood of writes or reads.) Consistent hashing also helps spread the fanout work evenly so no single machine gets overloaded.
How a fanout worker runs
1. Get the friend ids from the graph database (graph DBs are good at friend links)
2. Get each friend's info from the user cache (skip ones who muted or hid the user)
3. Send (friend list + new post id) to a message queue
4. Fanout workers read the queue and write into each friend's feed cache
5. Store <post_id, user_id> in the newsfeed cache
Step 5 is the key memory trick: the feed cache is a small <post_id, user_id> lookup table.
Storing whole posts and full user records would use far too much memory, so it stores only ids,
capped to a set number per user. (Most people only read the latest posts, so this rarely causes a miss.)
The phrase to land is "hotkey problem": pushing one celebrity's post to millions of feeds is where pure push falls apart. Suggest the hybrid (push for normal users, pull for celebrities) and mention a message queue to decouple the fanout workers plus consistent hashing to spread the load — that combination is exactly the senior answer.
Step 5: Deep dive — reading the feed
A feed is more than a list of ids. When the user calls GET /v1/me/feed:
1. Load balancer → web servers → newsfeed service
2. The newsfeed service reads the list of post ids from the newsfeed cache
3. Those ids get HYDRATED: fetch the full post (post cache) and the
user info — name, profile picture (user cache)
4. The finished feed is returned as JSON for the app to show
"Hydrate" just means turning a bare id into the full object behind it. Images and videos come from a CDN (a network of servers close to users) so they load fast and stay off the feed service's busy path.
The cache, in 5 layers
Caching is what makes a news feed fast. The cache splits into five layers:
| Layer | What it stores |
|---|---|
| News Feed | The post ids for each user's feed |
| Content | Every post's data; popular posts get a hot cache |
| Social Graph | Who follows whom |
| Action | Whether a user liked or replied to a post |
| Counters | Like, reply, follower and following counts |
Step 6: Wrap up
A news feed is two flows — publishing and reading — joined by a cache that stores only ids. The one choice that defines the design is fanout on write vs read, and the senior answer is the hybrid: push for normal users so reads are instant, and pull for celebrities so one post never sets off tens of millions of writes.
If you have time left, point to a few scaling topics:
- Database: scale up vs scale out, SQL vs NoSQL, master-slave replication, read replicas, sharding.
- System: keep the web tier stateless, cache a lot, run in multiple data centers, and decouple parts with message queues.
- Watch: track peak QPS and how long a feed refresh takes.
A news feed in 45 minutes: 5 min requirements + math → 5 min APIs → 10 min high-level (publish + read) → 20 min deep-dives (fanout push/pull/hybrid, hydration, cache layers) → 5 min scaling notes. If you remember one thing, remember hybrid fanout + a cache of ids — everything else hangs off those two ideas.
Practice
Answer these to check you understood how a news feed is built and read.
1. What does fanout mean in a news feed?
2. Why is pure 'fanout on write' (push) a bad fit for a celebrity with 50M followers?
3. What does the hybrid fanout model actually do?
4. Why does the feed cache store only <post_id, user_id> instead of whole posts?
5. What does it mean to 'hydrate' a feed?