The news feed shows up in system design interviews constantly. Twitter, Instagram, LinkedIn, Facebook - same core problem. A user opens the app and wants a list of recent posts from people they follow, ordered well, loaded fast.
It sounds simple. The trap is that the obvious design works fine until it doesn't, and the interviewer is testing whether you know where it breaks.
Here's how I think about it.
Start with the read, not the write
A feed is a read-heavy system. People scroll far more than they post. So the question that drives everything is: when a user opens their feed, where does that list of posts come from?
Two answers, and the choice between them is the whole interview.
Fan-out on read
When a user opens the app, you go fetch the recent posts from everyone they follow, merge them, sort them, and return the list.
This is simple to build. A post is one write to one table. Nothing fancy happens when someone posts.
The cost lands at read time. If I follow 500 people, opening my feed means querying 500 users' recent posts and merging them on the fly. Every single time I refresh. Multiply that by millions of active users and your database is doing an enormous amount of work for the most common action in the app.
Fan-out on read is good when follow counts are high, posts are frequent relative to reads, or you're early and want something that works.
Fan-out on write
The other approach: when I post, you immediately push that post into the precomputed feed of every one of my followers. Each user has their own feed list sitting in a fast store (usually Redis), ready to serve.
Now reads are cheap. Opening the feed is one lookup of an already-built list. That's the right place to spend, because reads are the common case.
The cost moves to write time. If I have 100,000 followers, one post becomes 100,000 writes. And if those followers are offline and won't open the app for days, you did that work for nothing.
Fan-out on write is good when reads vastly outnumber writes and most follow counts are modest.
The hybrid is the real answer
In a real system you do both, and saying so is usually what the interviewer wants to hear.
Fan-out on write for normal users. Fan-out on read for the celebrity case. When someone with millions of followers posts, you do not fan that out to millions of feeds. Instead you mark them as a special case and pull their posts in at read time, merging them into the precomputed feed when a follower loads it.
So a feed read becomes: grab my precomputed feed, then pull recent posts from the handful of huge accounts I follow, merge, sort, return. You get cheap reads for the common case and you avoid the write explosion for the rare account that would cause it.
That split - bulk handled one way, the long tail handled another - is a pattern worth recognizing. It shows up all over system design.
Ranking
Chronological order is the easy version. Newest first, done.
Ranked feeds are harder. You're now scoring each post on engagement, recency, relationship, and predicted interest, then sorting by score. That means you need the candidate posts in memory before you can rank them, which pushes you toward fetching more than you'll show and ranking the pool.
In an interview, I'd keep it chronological first to get a working design on the board, then say "if we want ranking, here's what changes." Don't open with the hard version and tangle yourself up.
Caching and pagination
The feed store itself is a cache - precomputed lists in Redis backed by the source-of-truth database. Cap each user's stored feed at some recent window (a few hundred posts), not their entire history. Nobody scrolls back two years.
For pagination, avoid offset-based paging (page 1, page 2). New posts arrive constantly and shift everything down, so offsets duplicate and skip items. Use a cursor - "give me posts older than this ID or timestamp." It's stable when the underlying list is moving.
What the interviewer is actually checking
They're not looking for the perfect architecture. They want to see that you:
- Started from the read/write ratio instead of jumping to a database schema.
- Named the fan-out tradeoff out loud and picked based on access patterns.
- Caught the celebrity edge case before being prompted.
- Knew that ranking and pagination have their own gotchas.
You don't need to memorize a diagram. You need to reason from the access pattern to the design and explain why. That's the skill, and it transfers to every other feed-shaped problem you'll get asked.
If you want to get smoother at saying this out loud under pressure, run it as a mock a few times. The thinking is one thing; narrating it clearly while someone watches is a separate muscle, and it's the one that actually gets graded.
For the complete design, with capacity estimates and the hybrid fan-out worked end to end, see the news feed system design walkthrough.