Design a News Feed: Ranking and Fan-Out Trade-offs

"Design a news feed" is one of the most common system design prompts, and most candidates blow it by jumping straight to boxes and arrows. The core of a good answer is two decisions: how you deliver a post to millions of followers (fan-out), and how you order what a user sees (ranking). Nail those two, explain the trade-offs, and handle the celebrity edge case, and you have covered what interviewers actually score. Everything else (storage, caching, CDNs) is supporting detail.

We run mock system design interviews all day, and the pattern is consistent: candidates who lead with the read/write path and the fan-out decision sound senior. Candidates who start listing databases sound like they memorized a diagram. Here is how to structure the answer.

Clarify scope before you draw anything

Feed problems are deliberately vague. Pin down the requirements in the first three minutes so you are solving the right system.

Read vs write ratio. Feeds are read-heavy, often by two or three orders of magnitude. That single fact justifies precomputing timelines.
Latency target. Feed load should feel instant. Assume a p99 budget around 200ms for the timeline fetch.
Ordering. Reverse-chronological or ranked? This changes everything downstream. Say which one and why.
Scale. Put numbers on it. Say 200M daily active users, average 200 followers, some accounts with tens of millions. The distribution matters more than the average, because the tail (celebrities) breaks the naive design.

Do the arithmetic out loud. If you want a refresher on turning these assumptions into QPS and storage numbers, our guide on back-of-the-envelope estimation covers the moves interviewers expect.

The core decision: fan-out on write vs fan-out on read

Every feed system answers one question: when do you assemble a user's timeline? There are two options.

Fan-out on write (push). When you post, the system immediately pushes your post into a precomputed timeline (usually a Redis list) for every follower. Reads are trivial: fetch one list, done. This is why feeds load fast.

Fan-out on read (pull). You store each post once. When a user opens the app, you fetch recent posts from everyone they follow and merge them at read time. Writes are cheap, reads are expensive.

The trade-off is a classic space-and-write-cost versus read-cost swap:

Dimension	Fan-out on write	Fan-out on read
Read latency	Very low (one list)	High (scatter-gather + merge)
Write cost	High (one write per follower)	Low (one write total)
Storage	High (duplicated per follower)	Low
Best for	Users with few followers	Accounts with huge follower counts

Twitter's own history is the cleanest illustration. Twitter started with fan-out on read, switched to fan-out on write in 2012 for better read latency, and later evolved to a hybrid. That evolution is the whole story of the problem in one sentence, and it is worth stating in the interview.

The celebrity problem, and the hybrid that actually ships

Pure fan-out on write dies on the tail of the follower distribution. Walk through the math, because interviewers want to see you find the failure mode yourself. A user with 50 million followers who posts a tweet generates 50 million Redis writes for that single tweet, and ten tweets a day is 500 million writes, which overwhelms the fanout system.

The fix is a hybrid keyed on follower count. For regular users with fewer than roughly 10,000 followers, use fan-out on write so their posts are pushed to follower timelines; for celebrities above that threshold, do not fan out, and instead store their posts separately. At read time you merge the precomputed timeline with a small number of freshly pulled celebrity posts. The threshold is a tuning knob, not a law: the ~10K figure is commonly cited in public discussions of the design, including Krikorian's InfoQ talk and the HighScalability summary of Twitter's timeline architecture.

Why this works is the key insight to verbalize: most users have few followers, but a small minority generates massive fan-out load, so treating those populations differently optimizes for both. Push handles the common case cheaply; pull rescues you from the fan-out storm at the top of the distribution.

Merging two sources at read time is a classic k-way merge, which is where a heap or priority queue earns its keep: you pull the newest post across the precomputed list and the celebrity posts, ordered by timestamp or score. The underlying follow relationships are a directed graph, and being explicit about that helps when the interviewer asks how you find a user's followees.

Edge cases interviewers probe

Cold start. A brand new user follows nobody, so there is no precomputed timeline to serve. Fall back to a recommended/discovery feed.
Merge timeout. A power user following thousands of accounts makes the pull side slow. Cap the number of followees queried and prioritize by recent engagement.
Deletes and edits. With fan-out on write, a deleted post lives in millions of lists. You need tombstones or a filter-on-read check against the source of truth.

Ranking: from reverse-chronological to a scored feed

Reverse-chronological is the easy answer, and for a first pass it is a fine one. Modern feeds rank instead, and interviewers at feed-heavy companies expect you to know the shape of a ranking pipeline even if you do not implement the model.

Meta has documented its approach publicly, and it maps to a clean four-stage pipeline. Feed ranking runs through four stages: inventory, signals, predictions, and a combined relevance score. In plain terms:

Inventory. Gather all candidate posts the user could see (from friends, Pages, Groups, plus recommended content).
Signals. Evaluate features about each post and the viewer: who posted it, post age, content type, past interactions.
Predictions. Score the probability of each action. Meta's systems predict how likely you are to comment on a post, how likely your friends are to comment if you share it, and whether a post is likely to spark back-and-forth discussion. They also use surveys: people are asked whether a post was "worth your time," and those answers train predictions about other content.
Relevance score. Combine the predictions into a single number and sort.

Architecturally, ranking usually runs as a two-pass system: a cheap candidate-generation pass narrows inventory to a few hundred posts, then an expensive model scores that shortlist. This keeps the model cost bounded regardless of how much content exists. You do not need to name a model in an interview; you need to say where scoring sits (after retrieval, before serving) and why you rank a shortlist rather than everything.

One more detail that signals depth: user-facing controls are part of the ranking product, not an afterthought. Users can see "Why am I seeing this?" and use controls like Favorites, See First, and Snooze. Mentioning that ranking has to be explainable and adjustable shows you think past the algorithm.

Putting it together: a serviceable architecture

A clean whiteboard answer has these components:

Write path: post service writes to a durable store (the source of truth), then emits an event to a fan-out service that pushes into follower timeline caches for non-celebrity authors.
Read path: timeline service reads the precomputed cache, merges in recent celebrity posts, applies ranking, and returns a page.
Storage: posts in a sharded store; timelines in Redis lists capped to a few hundred entries (you never need the millionth item); the social graph in its own service.
Ranking service: candidate generation plus a scoring model, sitting on the read path.

State the trade-off you are making at each hop. That habit, more than any single component choice, is what separates a mid-level answer from a senior one. If you want to drill this and related prompts with feedback, our system design practice sessions run the same clarify-estimate-design-defend loop interviewers use.

FAQ

Is fan-out on write always better because reads are faster?

No. It trades write cost and storage for read speed, which is the right trade for read-heavy feeds only up to a point. For accounts with millions of followers the write amplification is catastrophic, so those are handled with fan-out on read. The production answer is almost always a hybrid.

What follower count should trigger the celebrity path?

It is a tunable threshold, not a fixed rule, commonly discussed around 10,000 followers. Pick a number that bounds your worst-case write amplification, and say explicitly that you would tune it against real fan-out latency. Interviewers care that you know it is a knob, not the exact value.

Do I need to design the ranking model in the interview?

No. Describe the pipeline (inventory, signals, predictions, score) and where it runs (a scoring pass over a retrieved shortlist). Naming specific features and the two-pass retrieval-then-rank structure is enough to show depth without pretending to be an ML engineer.

How do I handle a user who follows thousands of accounts?

Cap the number of followees you query on the read side and prioritize by recent engagement, then rely on the precomputed timeline for the rest. This bounds scatter-gather latency and prevents merge timeouts. It is the read-side mirror of the celebrity problem.