News Feed System Design Interview: Fan-Out Walkthrough

The news feed system design interview shows up because it is a read-heavy fan-out problem with a hard latency budget, and because it forces one clear decision: do you assemble the feed when a post is written, or when it is read? Everything else — ranking, caching, pagination — hangs off that choice. This walkthrough follows the order a strong answer tends to take: requirements, data model, fan-out, ranking, read path, failure modes. Say the trade-offs out loud as you go; the interviewer is scoring the reasoning, not the diagram.

Why the News Feed Question Comes Up So Often

A feed has many readers and comparatively few writers. That asymmetry is the whole problem, and it is why interviewers reach for it: it makes precomputation versus on-demand assembly unavoidable.

What a strong answer sounds like:

Requirements first, stated as a short list you write down.
One core design, committed to and drawn.
Trade-offs named explicitly, with the condition that would flip your choice.
Failure modes and what breaks first at higher traffic.
A two-sentence summary at the end.

What a weak answer sounds like: a memorised diagram of boxes, no numbers, no alternatives, and no answer when asked "why this and not the other one?"

Spend the first few minutes clarifying scope before you draw anything. If you want a repeatable way to do that, the structure in Rate Limiter System Design Interview: Reasoning Out Loud shows the same habit of stating constraints before committing to a design.

Clarify the Requirements Before You Architect

Every news feed system design interview answer should start here, because the requirements decide the fan-out choice later.

Functional scope

Cover the surfaces you will actually design, and name the ones you are parking. A short, ordered list is enough.

Post creation, including text and media references.
The follow graph: follow, unfollow, and reading it.
Feed generation and delivery.
Ranking, or an explicit decision to launch reverse-chronological.
Pagination and scrolling.
Edit and delete propagation.

Non-functional targets

Read latency: a feed page should feel instant; treat the read path as the budget you protect.
Availability over strict consistency: a feed that is a few seconds stale is usually acceptable; a feed that fails to load is not.
Freshness: how long may a new post take to appear in a follower's feed? Seconds, minutes, or "best effort"?

Scale questions worth asking

Daily active users, average follows per user, posts per user per day, and the peak read-to-write ratio. If the interviewer gives you nothing, pick round numbers, write them down, and say which one you would revisit first if it moved by an order of magnitude.

A worked example makes this concrete. Purely as an illustration, suppose reads outnumber writes by about a hundred to one, and most users follow a few hundred accounts. Assembling a feed on demand means merging recent posts from every followee — on the order of hundreds of lookups per feed view, repeated for every one of those hundred reads. Fan-out on write does one unit of work per follower per post: a few hundred writes, once. So the comparison is roughly a hundred reads times hundreds of lookups against a few hundred writes once — which is why precomputing pays off when follower counts are modest. Then note the sensitivity yourself: "If the median user followed ten thousand accounts instead of a few hundred, I would change the fan-out choice, not the storage layer."

The Core Data Model and the Follow Graph

Three things need storing, and separating them keeps the design legible:

Users: profile and settings.
Posts: author, timestamp, content, visibility, and a status flag for deleted or edited.
Follow edges: follower to followee, written rarely and read constantly.

The follow graph is the interesting part. A relational table of edges is easy to reason about and supports queries like "who does this user follow?" and "who follows this user?" symmetrically. A wide-column store keyed by user, holding a list of followees (and a separate list of followers), makes the read a single lookup, which matters because feed generation reads it on every request or every fan-out. The trade-off is that reverse lookups — "who follows me?" — need their own table.

What each store buys you is the part worth saying out loud. A wide-column store scales the hot read path better: the followee list for one user sits together, so a lookup touches one partition instead of joining many edge rows, and the store spreads partitions across nodes as the graph grows. A relational store gives you stronger consistency guarantees on follow and unfollow, plus ad-hoc queries and constraints that are awkward to express in a key-value model. So the condition is roughly this: pick the wide-column store when the read path is hot and the access pattern is known, and pick the relational store when the graph is smaller, when you need transactional follow/unfollow, or when you expect to query it in ways you cannot predict yet. Many designs keep both — relational as the source of truth, a denormalised wide-column copy for the read path — and say so.

Then there is distribution. A user with a few hundred followers and a user with millions are not the same problem. Say that early; it sets up the hybrid fan-out decision later.

Keep post content in one store and feed metadata — ordered lists of post IDs — in another. Content is large and immutable-ish; feed lists are small, hot, and disposable. Separating them means you can cache and evict feed lists aggressively without touching the content store.

Fan-Out on Write vs Fan-Out on Read

This is the heart of the news feed system design interview, so slow down here and make the choice explicit.

Fan-out on write

When a user posts, push the post ID into a precomputed feed list for each follower.

Reads are fast: fetch the list, hydrate the posts, return.
Writes are expensive and bursty: a post by a popular account triggers a large fan-out job.
Storage amplifies: the same post ID is stored once per follower.
Staleness is low, because the list is already built.

Fan-out on read

Store posts by author. When a reader opens the feed, pull recent posts from each followee and merge.

Writes are trivial: one row per post.
Reads get heavy: merge across many followees, then rank.
Ranking is easier to change, because nothing is precomputed.
Tail latency grows with how many accounts the reader follows.

The hybrid most candidates should land on

Precompute feeds for ordinary users, and pull at read time for accounts with very large follower counts. When a high-follower account posts, do not fan out to millions of lists; instead, merge that author's recent posts into the reader's feed when the reader asks for it.

Phrase the decision the way an interviewer wants to hear it: "I would start with fan-out on write because most users have modest follower counts and reads dominate. I would switch the high-follower accounts to read-time merging when the follower distribution has a long tail, because write amplification and storage cost scale with followers, and I would rather pay a little extra latency for those readers than run a fan-out job that takes minutes."

Name the costs explicitly: write amplification, storage growth, tail latency on the read path, and how stale the precomputed list can get.

Ranking: From Reverse Chronological to Relevance

Start simple. Reverse chronological is a legitimate v1, and saying so shows judgement rather than a lack of ambition. Then explain what changes when relevance enters — this is the part of the news feed system design interview where many candidates either overreach or go silent.

The usual shape is a funnel:

Candidate generation — gather a few hundred plausible posts: recent posts from followees, plus a small number of recommended items.
Lightweight scoring — cheap signals to cut the candidate set down.
Heavier ranking — a more expensive pass over the survivors, producing the final order.

Signals worth mentioning: recency, affinity between viewer and author, engagement history, and content type. You do not need to design a production machine learning system. You need to place ranking sensibly in the pipeline and say where it runs.

That placement is a real decision:

Rank at write time: the precomputed list is already ordered, so reads are cheap, but every ranking change requires a rebuild and the order cannot depend on who is reading.
Rank at read time: fresh and personalised, but it adds latency to the path you were protecting.
Two-stage split: cheap ordering at write time, a final personalised pass at read time over a small candidate set. This is usually the right answer, and it is worth saying why: it keeps the expensive work bounded. The write-time order gives the read-time pass a sensible starting point, and the candidate set is capped — a few hundred items, not the whole feed — so the heavier pass fits inside the read latency budget you set earlier.

Caching, Pagination and the Read Path

In any news feed system design interview, the read path is where your earlier choices get tested. Cache the assembled feed per active user, not raw posts. The assembled list is what the read path needs, it is small, and it can be regenerated if lost. Discuss eviction honestly: an LRU-style policy with a short time-to-live is a reasonable default, and a cold cache should degrade to computing the feed on demand rather than failing.

Pagination for a ranked feed is genuinely hard, and it is a good place to show depth. Offset paging breaks when the ranking shifts between requests: items slide, and users see duplicates or gaps. Cursor-based paging — a stable cursor pointing at a position in a snapshot of the ranking — is the better answer. It also handles new posts arriving mid-scroll: new items land above the cursor, and the reader's current page stays stable. Say that a stable cursor matters more than perfect freshness.

Read-path failure modes to raise before you are asked:

Cache stampede: a hot user's cached feed expires and many requests recompute it at once. Request coalescing — letting one request compute while others wait briefly — or serving slightly stale data while a refresh runs in the background both help.
Hot keys: one celebrity's posts appear in millions of feeds. Read-time merging for those accounts, plus caching their recent posts separately, limits the blast radius.
Thundering herd on deploy: warm the cache for active users rather than letting it fill from zero.

Consistency, Deletion and Failure Modes

Eventual consistency. A post may take a moment to appear in followers' feeds. Translate that into user-visible terms: the author sees their own post immediately because their own timeline is read directly from the post store; followers see it within a short window. That distinction — author sees instantly, followers see soon — is usually acceptable and worth stating plainly.

Deletion and edits. If a post has already fanned out to millions of feed lists, do not rewrite them all. Write a tombstone in the post store, mark the post as deleted, and filter it during hydration. Edits can follow the same pattern: keep the post ID stable and let hydration read the current version. Say that this trades a small amount of read-time filtering for a large saving in write work.

Partial fan-out. If a fan-out worker dies halfway through, some followers get the post and some do not. The fix is to make fan-out idempotent and resumable — track progress per post, and run a backfill job that recomputes feeds for the affected range. Mentioning idempotency here is a strong signal.

"What breaks first at 10x traffic?" A workable answer: the fan-out path for high-follower accounts, then cache hit rate on the read path, then the ranking pass if it runs synchronously. Each has a mitigation you already named.

Practising the Walkthrough Out Loud

Rehearse the shape, not a script: requirements, core design, trade-offs, failure modes, summary. One allocation that fits a 45-minute interview, if you want a starting point, is roughly five minutes of scoping, twenty of design, five of trade-offs, and the rest for follow-ups — adjust it to how the conversation actually goes.

A few habits that make the difference:

Time yourself and note where you overran.
Record yourself and listen for the moments you went quiet. Silence is usually where the reasoning stopped, not where knowledge ran out.
Practise saying "I would start with X because of Y, and switch to Z when the follower distribution looks like this." That sentence is the answer to most follow-up questions.
Reuse the same structure on other cases, so the framework becomes automatic and your attention stays on the problem. The sorting coding interview walkthrough applies the same habit of narrating reasoning to a different kind of question.

One last habit worth building: write down your assumptions as you state them. When the interviewer pushes back, you can point at the number you chose and explain what changes if it moves. That is what separates a rehearsed answer from a reasoned one.

The skill is yours to build, and it improves with repetition: answer aloud, then review how you structured the answer and where the reasoning stalled. For more walkthroughs to practise against, see the blog.

Frequently asked questions

How deep should I go on ranking in a news feed system design interview?

Enough to place it correctly in the pipeline: describe the funnel, name a few signals such as recency and affinity, and say whether ranking runs at write time, read time, or as a two-stage split. You are not expected to design a production machine learning system.

Should I choose fan-out on write or fan-out on read?

Start with fan-out on write if reads dominate and most accounts have modest follower counts, then carve out high-follower accounts to read-time merging. Say the condition that would flip your choice — a long follower tail, or a ranking change that must apply retroactively.

How do I handle pagination in a ranked feed?

Use cursor-based paging over a snapshot of the ranking rather than offset paging, which breaks when the ranking shifts between requests. A stable cursor also keeps the current page in place when new posts arrive mid-scroll.

What scale numbers should I assume if the interviewer gives none?

Pick round, memorable numbers, state them out loud, and write them down: daily active users, average follows per user, posts per user per day, and the peak read-to-write ratio. Then name which assumption you would revisit first if it changed by an order of magnitude.

Do I need to design the machine learning model behind the ranking?

No. Explain where ranking sits, what it consumes, and what it costs in latency, and note that the model itself is a separate system. Treating the ranker as a service with a latency budget is a stronger answer than inventing model details.

How long should the news feed system design interview walkthrough take in a 45-minute interview?

There is no fixed rule, but one suggested allocation is about five minutes of scoping, twenty of core design, five of trade-offs and failure modes, with the rest for follow-ups. If you are running long, cut breadth — park features explicitly — rather than skipping the trade-offs.