Design a social media news feed or timeline — how do fan-out-on-write and fan-out-on-read compare?

#Framing the problem: where does the work happen?

A news feed is a personalized, time-ordered (or relevance-ranked) merge of posts from everyone a user follows. The interesting engineering question is never "how do I store a post" — it's "who does the work of assembling a user's feed, and when." There are exactly two moments where that work can happen: when a post is written, or when a feed is read. Every design is a choice about which side absorbs the cost, and the two dominant strategies — fan-out-on-write and fan-out-on-read — sit at opposite ends of that trade-off.

Both strategies assume the same underlying primitives: a posts store keyed by post ID, a follows graph (who follows whom), and per-user feed storage of some kind. What differs is when the fan-out — literally, "spreading one post out to many followers' feeds" — actually executes.

#Fan-out-on-write (the push model)

In fan-out-on-write, the system does the expensive work immediately, at post time. When a user posts, a fan-out worker looks up their entire follower list and pushes a reference to the new post (usually just a post ID plus a score for ranking, not the full post body) into every follower's precomputed feed — typically a capped, sorted structure like a Redis sorted set, one per user.

Reading a feed is now nearly free: fetch the caller's own precomputed list, paginate, hydrate post bodies from the posts store, done. This is O(1) relative to how many people you follow, which is exactly why it feels instant in the product.

The cost is on the write path, and it scales with the poster's follower count, not with any fixed constant. A user with 500 followers triggers 500 small writes. A user with 5 million followers triggers 5 million writes from a single post — the majority of which are wasted work, since most of those followers won't open the app before that post has scrolled off the bottom of their feed anyway.

#Fan-out-on-read (the pull model)

Fan-out-on-read inverts the trade: writes stay cheap, reads get expensive. Posting is just an append to the author's own timeline — O(1), no matter how many followers they have. There is no fan-out worker and no per-follower write at all.

The cost moves entirely to read time. When a user opens their feed, the service fetches their follow list, queries the most recent posts from every one of those authors (often in parallel), merges the results by timestamp or rank, and paginates. If you follow 2,000 accounts, that read touches (in the naive case) 2,000 source timelines before it can return the top 20 posts.

This avoids the write amplification and wasted storage of the push model entirely, but it shifts the bottleneck to fan-in at read time, and read time is exactly when users are most latency-sensitive.

#The celebrity problem, and the hybrid that fixes it

Neither pure strategy survives contact with a real social graph, because follower counts are not remotely uniform — they follow a power law. Pure fan-out-on-write collapses under celebrity accounts: a single post from an account with 50 million followers means 50 million feed writes fired at once, a genuine "thundering write herd" that can degrade the entire feed-cache tier for everyone, not just that celebrity's followers. Pure fan-out-on-read collapses for ordinary heavy users: someone who follows 3,000 accounts pays a 3,000-way fan-in on every single feed refresh, even though almost none of those accounts posted anything new since their last check.

The practical answer used across the industry is a hybrid: push for everyone under a follower threshold, pull for everyone over it. Normal accounts still get fan-out-on-write, so most feed reads stay a cheap O(1) lookup. Accounts above the threshold — celebrities, large media accounts — are flagged and excluded from fan-out entirely. At read time, the feed service merges the user's precomputed pushed feed with a small, targeted live query against just the celebrity accounts that user follows (rarely more than a handful, even for someone who follows thousands of regular accounts).

#Trade-offs at a glance

#Practical details that matter in an interview

Precomputed feeds are always capped — nobody stores an unbounded list per user. A typical implementation keeps only the most recent few hundred entries per user's feed cache; scrolling further back than that falls through to a pull-style query against the underlying stores as a fallback, which is itself a small hybrid decision. Deletes and edits also have to fan out in the push model — if a post is deleted, every follower's cached reference to it needs to be invalidated too, which is easy to forget and easy to get wrong.

It's also worth naming that most production feeds aren't strictly chronological — they're ranked by a relevance model, which means even a "push" architecture still does real computation at read time (scoring and re-sorting the candidate set), it just doesn't do the expensive fan-in across thousands of source timelines. The fan-out decision and the ranking decision are separate axes of the same system.

🧠 Check your understanding
0/3 · 0/3 answered
1. A user follows 4,000 accounts and refreshes their feed constantly. Which fan-out strategy makes each of their reads most expensive?
Hybrid with a low celebrity thresholdFan-out-on-readFan-out-on-writeNone — read cost is independent of the strategy
2. Why does pure fan-out-on-write break down for celebrity accounts specifically?
Fan-out-on-write cannot store posts longer than 280 charactersA single post triggers a write proportional to follower count, which can be tens of millionsCelebrities post less often than average usersCelebrity posts are larger in size than regular posts
3. In the hybrid model, what happens when a celebrity account posts?
The post is fanned out to a random sample of followersThe write stays cheap (append-only); it is merged into followers' feeds via a live query at read timeThe post is fanned out but delayed by several hoursThe post is rejected until follower count drops below the threshold