A follow-based feed (Twitter/Instagram home timeline) is the canonical fan-out problem, and it comes down to one decision with a famous exception: do you precompute each user's feed when someone posts (fan-out on write, fast reads, explosive celebrity writes) or assemble it when they open the app (fan-out on read, cheap writes, expensive reads)? This case study works the prompt through the framework, lands on the hybrid that every real feed uses, and shows why a celebrity with fifty million followers is the whole reason the naive answer breaks.

Design a news feed

"Design a news feed" (a Twitter/Instagram home timeline) is the prompt that teaches fan-out, and it's worth doing because the naive answer is obviously right, works fine at small scale, and then shatters on one specific input: a user with tens of millions of followers. Run it through the framework.

Requirements

Functional: users follow other users; a user posts; a user opens their home feed and sees recent posts from the people they follow, in some order. Defer: comments, likes, DMs, stories.

Non-functional: read-heavy (people scroll far more than they post), low-latency feed load (the feed must open instantly), eventual consistency is fine (a post appearing in feeds a few seconds late is completely acceptable — nobody's balance depends on it), and huge asymmetric fan-out — one post may need to reach anywhere from 50 to 50,000,000 feeds. That last property is the entire problem.

Estimates

Say 500M daily users each opening the feed ~10×/day → tens of thousands of feed-reads/sec, easily more at peak. Posts are far fewer. But the number that dominates is fan-out volume: if the average user has 200 followers, each post generates ~200 "deliver to a feed" operations — and a celebrity with 50M followers generates 50 million per post. Multiply by posts/sec and fan-out, not raw reads, is the workload that decides the architecture.

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

Everything hinges on when you assemble a user's feed.

Fan-out on write (push model). When you post, immediately write that post into the precomputed feed of every one of your followers (typically a per-user list in a cache like Redis). Then reading a feed is trivial and blazing fast — just read your ready-made list, no computation. This is great for the read-heavy requirement… until the write side. A post by someone with 50M followers triggers 50M feed writes — a massive, spiky, expensive operation for a single post, and largely wasted effort on the followers who won't open the app today. Push makes reads cheap by making celebrity writes catastrophic.

Fan-out on read (pull model). Store each post once. When a user opens their feed, query the recent posts of everyone they follow and merge them on the fly. Writes are now trivial (one insert per post). But reads are expensive — a user following 2,000 accounts triggers a gather-and-merge across 2,000 authors every time they open the app — and reads are the frequent operation, so you've made the common case slow. Pull makes writes cheap by making every read expensive.

Neither pure model works at scale: push dies on celebrities, pull dies on active readers. So real systems use the hybrid, and naming it is the point of the whole prompt:

Fan-out on write for normal users — most people's posts push into their followers' precomputed feeds (fast reads for the common case).
Fan-out on read for celebrities — accounts above some follower threshold do not fan out on write. Their posts are pulled instead.
A feed read = merge the user's precomputed (pushed) feed with a live pull of recent posts from the handful of celebrities they follow. The pushed part is cheap-read; the pulled part is small (you follow few celebrities), so the merge is fast.

This kills the celebrity explosion (no 50M writes per celebrity post) while keeping normal reads fast, and it's essentially what every production feed does.

The celebrity is the whole problem — and why pure push is a trap

The failure that defines this design: you build fan-out-on-write because reads must be fast, it works beautifully in testing and for ordinary users, and then a celebrity posts. That single post enqueues tens of millions of feed-write operations, saturating your write path, delaying everyone's fan-out (normal users' posts are now stuck behind the celebrity's 50M writes in the queue), and hammering the feed cache — one post nearly takes the system down. And most of that work is wasted: the vast majority of those 50M followers won't open the app before the post is stale. This is why "just precompute everyone's feed" is a trap that only reveals itself at scale, and why the follower-count distribution — a few accounts with enormous followings, most with few — forces the hybrid. The senior move is to anticipate the celebrity in the deep-dive before the interviewer raises it: "fan-out on write, except I special-case high-follower accounts to fan-out on read, because otherwise one celebrity post is tens of millions of writes." The fan-out work itself, incidentally, is classic queue territory — you don't do 50,000 feed writes synchronously in the post request; you enqueue the fan-out and a worker drains it, so posting stays fast and the fan-out absorbs into a backpressure-managed queue.

Other deep-dives

Ranking. Chronological is simplest (merge by time). "Ranked" feeds score candidate posts by a model (engagement, recency, affinity) — architecturally, it's a scoring pass over the merged candidate set, so the fan-out design is unchanged; ranking sits on top.
Storage & consistency. Posts live in a store sharded by author; the follow graph is its own store; precomputed feeds live in a cache. Because eventual consistency is acceptable, you get to use all the fast, available, AP/EL tools freely — a feed is the textbook case where stale-for-a-few-seconds is completely fine, which is why it can be so aggressively cached and asynchronously fanned out.

Wrap-up

Bottlenecks: the fan-out workers (scale horizontally, prioritize so celebrities don't starve normal users), the feed cache (hot, huge), and the celebrity threshold (a tuning knob, not a constant). What you left out: real ranking, spam, the cold-start problem for new users. All fine to defer — naming them is the senior close.

Where this lives in Fable

Fable has no social feed, and that's worth saying plainly rather than pretending — it's a group-expenses app, not a follow graph. But it's illuminating because it's the degenerate easy case of this exact problem. A group's chat-and-activity timeline is a feed, and "when someone posts, deliver it to everyone who should see it" is fan-out — but in Fable the audience of any post is one group's members, a bounded, tiny set (a handful to a few dozen), never millions of followers. So Fable does the equivalent of fan-out on write with impunity: the realtime layer pushes each message to the group's Socket.IO room, which is exactly precomputing-and-pushing to a follower set — and it's trivially fine because the "follower set" is always small and there is no celebrity. The whole hybrid/celebrity apparatus this lesson builds exists to handle the one thing Fable's data model structurally forbids: an unboundedly large audience for a single post. So if an interviewer asked me to extend Fable into something with a public feed, this is the lesson I'd reach for — and the honest framing is "today fan-out is free because N is tiny and bounded by group size; a public feed breaks that assumption, and that's when you need push/pull hybrid and a celebrity special-case." Knowing why your current design is easy is knowing exactly what would make it hard.

Go deeper

Twitter — "Timelines at Scale" (Raffi Krikorian) — The original, definitive talk on fan-out-on-write, the celebrity problem, and the hybrid — the real system this prompt is abstracted from.
System Design Primer — social feed / fan-out — A worked treatment of the push/pull models and the hybrid with the data structures and estimation, structured like this case study.
Redis lists — precomputed feeds — The concrete data structure behind fan-out-on-write: per-user feed lists you push into and trim, and why a cache is where precomputed feeds live.

Check yourself

Answer out loud, as if an interviewer asked. If you hand-wave, reread that section.

What single property of a news feed dominates the architecture, and why is raw read volume not the number that matters most?
Contrast fan-out on write and fan-out on read on both the read cost and the write cost. State the specific input that breaks each pure model.
Describe the hybrid model precisely: what normal users get, what celebrities get, and what a single feed read actually does (the merge). Why does this defuse the celebrity problem?
Walk through what happens to a pure fan-out-on-write system when a 50M-follower account posts, including the effect on other users' posts, and why a queue is involved in fan-out at all.
Why is eventual consistency acceptable for a feed, and how does that permission change which storage and caching tools you can use?
Fable fans out every message to a group with no celebrity problem. Explain why its fan-out is "free," what assumption makes it so, and what would break that assumption.

Design a news feed

Design a news feed

Requirements

Estimates

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

Other deep-dives

Wrap-up

Go deeper

Check yourself

On this page