Facebook News Feed System Design: The Classic Interview Question
If you only prepare one system design question before your interview, prepare this one. "Design Facebook's News Feed" (or Twitter's timeline, or Instagram's home feed) shows up everywhere because it forces you to make a real trade-off with no perfect answer. The interviewer is not testing whether you know Facebook's actual architecture. They are testing whether you can reason about reads, writes, and what happens when one user has 100 million followers.
What Are the Requirements for a News Feed?
Always start by scoping the problem. A news feed sounds simple, but you need to pin down what you are actually building.
Functional Requirements
- A user can publish a post (text, image, video).
- A user can view a feed: a list of recent posts from people and pages they follow.
- The feed loads fast and supports infinite scroll (pagination).
Non-Functional Requirements
- Low latency: the feed should load in a few hundred milliseconds. Users abandon slow feeds.
- High availability: a feed that is slightly stale is fine; a feed that is down is not. We choose availability over strict consistency.
- Eventual consistency: if your friend's post takes a few seconds to appear in your feed, nobody notices. This one relaxation makes the whole design possible.
Say that consistency trade-off out loud in the interview. It signals you understand feeds are read-heavy and availability-first, and it earns you permission to cache aggressively.
Feed Publishing vs Feed Generation: The Two Halves of the Problem
Every news feed system splits into two independent flows, and naming them early keeps your whiteboard organized.
Feed publishing is the write path: a user creates a post, it gets stored, and the system decides who should eventually see it. Feed generation is the read path: a user opens the app and the system must assemble their feed, ideally without doing any heavy work at that moment.
The entire design question comes down to one decision: when do you do the expensive work of building each user's feed? At write time, when the post is published? Or at read time, when the user opens the app? That question has a name in system design: fanout.
Fanout-on-Write vs Fanout-on-Read: Which Should You Choose?
Here is an analogy I use with my students. Think of a newspaper. There are two ways to get news to readers. Option one: the press prints a copy for every subscriber and delivers it to each doorstep overnight, ready to pick up. Option two: no deliveries; whoever wants the news walks to the press and has an edition assembled on the spot. The first is fanout-on-write. The second is fanout-on-read.
Fanout-on-Write (Push Model)
With fanout-on-write, the work happens at publish time. Here is the step-by-step flow:
- Alice publishes a post. The post is written once to the posts database.
- The system looks up Alice's follower list from the social graph service.
- A fanout service pushes the post ID into a precomputed feed cache for every follower, usually via an async message queue so Alice's request returns instantly.
- When Bob opens his app, his feed is already sitting in cache. The read is a single fast lookup.
- Pros: reads are extremely fast, and reads massively outnumber writes on social platforms. You optimize for the common case.
- Cons: a post from a user with millions of followers triggers millions of cache writes. You also waste work on inactive users, precomputing feeds for people who have not logged in for months.
Fanout-on-Read (Pull Model)
With fanout-on-read, publishing is cheap: the post is written once and nothing else happens. The work moves to read time:
- Bob opens his app.
- The system fetches Bob's list of followees.
- It queries recent posts from each of them, merges the results, sorts, and returns the feed.
- Pros: writes are trivial, no wasted work for inactive users, and the feed is always perfectly fresh.
- Cons: every feed load fans out into hundreds of queries. If Bob follows 800 people, that is 800 lookups, a merge, and a sort while he stares at a spinner. Latency suffers exactly where users feel it most.
Be honest about the trade-off: neither model wins outright. Push punishes popular writers. Pull punishes heavy readers. That tension sets up the answer interviewers are waiting for.
The Celebrity Problem and the Hybrid Approach
The breaking point of pure fanout-on-write is called the celebrity problem (you may also hear "hot key" or "hotspot" problem). When a celebrity with 100 million followers posts a photo, a pure push model must insert that post into 100 million feed caches. Even at a million writes per second, that single post takes minutes of cluster-wide effort, and thousands of celebrities post every hour. The write storm delays everyone's feed.
The standard solution is a hybrid fanout:
- Regular users (the vast majority, with hundreds or a few thousand followers) use fanout-on-write. Their posts are pushed to followers' feed caches.
- Celebrities (accounts above a follower threshold, say one million) use fanout-on-read. Their posts are written once and never pushed.
- At read time, the system takes Bob's precomputed feed from cache, separately fetches recent posts from the few celebrities Bob follows, and merges the two lists before returning.
Most users follow only a handful of celebrities, so the read-time merge stays cheap. You get push-model speed for the common case and avoid the write storm for the hot case. This hybrid answer, stated with the reasoning behind it, is the single highest-value moment in the whole interview.
How Do You Structure the Feed Cache?
The feed cache is the heart of the read path, so be ready to describe it concretely. A common design uses an in-memory store like Redis:
- Key: the user ID. Value: a sorted list of post IDs (for example a Redis sorted set, scored by timestamp or rank).
- Store only post IDs, not full post content. Full posts live in a separate post cache and database. This keeps each feed entry tiny and avoids duplicating a viral post across millions of feeds.
- Cap the list at a few hundred entries per user. Almost nobody scrolls past that; deeper history can fall back to a slower query path.
- On read: fetch the ID list, then hydrate the top IDs (fetch author, text, media URLs, like counts) from the post cache in one batched call.
Because this cache takes almost all of the read traffic, it must be partitioned across many machines. Distributing user IDs across cache nodes is exactly the problem consistent hashing solves, and the caching layer itself follows the patterns covered in my guide to caching strategies. The posts database underneath is read-heavy too, so it typically runs with master-slave replication: writes go to the primary, feed hydration reads go to replicas.
How Does Feed Ranking Work?
Once the mechanics work, interviewers often push on ordering. Keep the story simple and honest.
Version one is chronological: sort merged posts by timestamp, newest first. It is easy, predictable, and what early Facebook and Twitter actually shipped. Say this first; simple baselines are a strength, not a weakness.
Version two is scored ranking. Chronological feeds bury the posts users care about under whatever was posted most recently. So modern feeds compute a relevance score per candidate post using signals like:
- Affinity: how often you interact with this author.
- Engagement: likes, comments, and shares the post is already getting.
- Content type: whether you personally watch videos or skip them.
- Recency: older posts decay in score.
In production this becomes a machine learning model predicting the probability you will engage with each post, but in a general system design round you are not expected to design the model. Say that a ranking service scores the candidate posts at read time, sorts by score, and returns the top N. Ranking adds computation to every feed load, which is another reason the candidate list must already be small and cached; if latency budgets are new to you, start with my beginner's guide to latency.
Capacity Estimation: Quick Numbers That Show Judgment
You do not need precise math, just defensible intuition. Assume 2 billion users, 1 billion daily actives, and each active user refreshes their feed 10 times a day: that is 10 billion feed reads per day, roughly 115,000 reads per second on average, with peaks several times higher. Writes are far smaller: if 1 in 10 daily actives posts once a day, that is about 1,200 posts per second.
The ratio is the insight: reads outnumber post writes by roughly 100 to 1. Quote that ratio and conclude that the system must be optimized for reads, which is precisely why we precompute feeds at write time for most users. Fanout multiplies those 1,200 posts per second by the average follower count (say 200), giving around 240,000 cache inserts per second, which a partitioned Redis fleet behind an async queue absorbs comfortably. Interviewers notice when your numbers and your design agree.
Want to master this with video lessons and real case studies? This topic is covered in depth in my Udemy course System Design Fundamentals for Interviews — 5.5 hours, rated 4.8★, built from real interview questions.
How to Talk About This in an Interview
Structure beats knowledge in this question. Spend two minutes on requirements, draw the write path and read path separately, present both fanout models with their costs, then land the hybrid. Volunteer the celebrity problem before the interviewer raises it; that is the difference between a good answer and a strong hire signal.
Your 30-Second Answer
"A news feed has two flows: publishing (write) and generation (read). Since reads dominate writes by about 100 to 1, I precompute feeds using fanout-on-write: when someone posts, an async fanout service pushes the post ID into each follower's cached feed list, so reads are a single cache lookup. Pure push breaks for celebrities with millions of followers, so I use a hybrid: celebrity posts are pulled and merged at read time instead. The feed cache stores post IDs in Redis sorted sets, hydrated from a post store, and a ranking service scores candidates before returning the top N. The system is eventually consistent, which is acceptable for a feed."
Practice that until it takes half a minute. It touches every pillar of the design and leaves the interviewer with threads to pull on, each of which you are now prepared for.
Key Takeaways
- Split the problem into feed publishing (write path) and feed generation (read path) before designing anything.
- Fanout-on-write gives fast reads but expensive writes; fanout-on-read gives cheap writes but slow reads. Neither is strictly better.
- The celebrity problem breaks pure push; the fix is a hybrid: push for regular users, pull and merge for celebrity posts.
- The feed cache stores post IDs only, capped per user, hydrated from a separate post store.
- Start ranking chronologically, then evolve to a scoring service using affinity, engagement, and recency signals.
Next Steps
You have now designed the most-asked feed question in system design interviews. Next in the series we tackle another favorite: designing Google Typeahead (search autocomplete), where the challenge flips from fanout to serving suggestion results in under 100 milliseconds per keystroke using tries and aggressive caching. See you there.