hard News Feed: Fan-out-on-Write vs Fan-out-on-Read

A feed read is always the same query — the choice is WHEN you pay for it

Every home-timeline read answers one question: "in time order, show me the recent posts from everyone I follow." You can either precompute that merged answer the moment someone posts (fan-out-on-write, "push") so a read is just a cache lookup, or you can compute it live every time someone opens their feed (fan-out-on-read, "pull") so a post is just a single durable write. Push moves cost to the write path and amplifies it by follower count; pull moves cost to the read path and amplifies it by follow count. Neither is free — you are choosing which side of the request pays.

Traced: the same action, two very different bills

Account	Followers	Fan-out-on-write cost per post	Fan-out-on-read cost per post
Average user	200	200 timeline writes — cheap	0 writes; cost shifts to each of their followers' reads
Celebrity	100,000,000	100,000,000 timeline writes — one post, 100M writes	0 writes; the post sits once in storage

Under pure fan-out-on-write, the celebrity's single post is not one database operation — it is a fan-out job that must touch 100 million distinct timeline records, one per follower, because each follower's timeline is a separate cached object and there is no way to deduplicate a write to 100M different destinations. Even at a sustained 50,000 writes/sec on the fan-out tier, that one post takes 100,000,000 ÷ 50,000 = 2,000s ≈ 33 minutes to fully propagate — "stale fan-out": some followers see it minutes after it was posted, and the queue backs up further if several celebrities post around the same event (a goal, a keynote, breaking news).

Under pure fan-out-on-read, that same post costs zero writes. It is stored once. Every follower who wants to see it pays a small merge-in cost at their own read time — and because it is the same shared post object, it is trivially cacheable: one hot cache entry can serve all 100M reads, instead of 100M separate cache writes that can never share work.

Why feeds default to push — the read:write ratio

Social feeds are read-heavy: a typical user scrolls their feed many times for every one time they post. If you precompute the merge once at write time, that one unit of work is amortized over every subsequent read — each read becomes an O(1) cache lookup. If you compute it live on every read instead, you redo the same merge work over and over for the same result. So when reads ≫ writes and follower counts are bounded, push wins outright: pay once, serve cheaply forever.

The celebrity problem inverts the calculus locally

The read:write argument assumes follower counts are modest. It breaks the moment one account has orders of magnitude more followers than a normal user. For that one account, "fan-out-on-write" no longer means "a little work, amortized" — it means a write storm sized to the follower count, regardless of how few times that celebrity posts. Push stops being cheap exactly where it is needed most: the accounts everyone wants to read.

The hybrid: push for the many, pull for the few

Real systems (Twitter/X, Instagram) never pick one mode globally. They push for every account below a follower threshold T (the vast majority of accounts, where push stays cheap), and exempt accounts above T from fan-out entirely. A reader's timeline is then two things merged at read time: their precomputed (pushed) timeline, plus a live pull of any posts from the small number of celebrities they personally follow — typically a handful, not millions, so that merge step stays cheap even though it happens on every read.

Pitfalls

• Synchronous fan-out blocks the poster on however many followers they have — always fan out asynchronously through a queue, and durably store the post before enqueuing.
• No celebrity threshold — without one, a single viral account can produce a fan-out storm that delays fan-out for every other user sharing that queue.
• Deletes and edits — a pushed timeline holds post ids, not content; a deleted or edited post must still resolve correctly when the timeline is hydrated, or followers see stale content.
• Unbounded pull merges — if a "normal" account is allowed to grow past the pull threshold without ever being reclassified, its followers silently pay a growing per-read merge cost.

Judgment layer: push vs pull vs hybrid

Use fan-out-on-write (push) when the read:write ratio is high and follower counts are bounded — the common case for most accounts on any social graph. You gain O(1) reads; you pay write amplification proportional to followers, plus storage for the duplicated timeline entries, plus the operational cost of an async fan-out pipeline.

Use fan-out-on-read (pull) when follower counts are extreme (celebrities), when writes and reads are closer to balanced, or when a stronger consistency/freshness guarantee matters more than read latency — pull always reflects current state with nothing to propagate or invalidate across N copies. You gain O(1) writes and no fan-out storms; you pay a merge cost on every read, which is harder to make cheap unless the merged set is small and cacheable.

Use the hybrid — the senior answer — for any real feed system: it is not a compromise, it is applying push and pull each where they are individually cheap. The only design decision left is the threshold T (tuned from the write-amplification budget of the fan-out tier: pick T where fan-out cost per post stops being negligible) and making sure accounts are re-classified as their follower count crosses it.

Takeaways

• A feed read is one query — merge posts from who you follow. Push precomputes that merge; pull computes it live. You are choosing which side of the request pays.
• Push amortizes across many cheap reads — correct default when reads ≫ writes and follower counts are bounded (200 followers → 200 writes/post).
• Extreme follower counts break push: 100M followers → 100M writes for one post, a fan-out storm with stale-fanout risk — the celebrity problem.
• The hybrid (push the many, pull the few, merge at read time) is what real systems run — not a single global strategy, but the right strategy per account.

---

Re-authored for this guide; fan-out comparison diagram hand-authored as SVG. Synthesizes the classic Twitter/X timeline architecture discussions (engineering blog + DDIA-style trade-off framing) and standard system-design interview treatments (Grokking/DesignGurus, Hello Interview). See also: "Designing Twitter Timeline — Fan-out Traced" (the build-it walkthrough this page's decision framework generalizes), Caching, Messaging System, Capacity Estimation.

I just read a lesson on **News Feed: Fan-out-on-Write vs Fan-out-on-Read** (System Design) and want to truly understand it. Explain News Feed: Fan-out-on-Write vs Fan-out-on-Read from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Teach me **News Feed: Fan-out-on-Write vs Fan-out-on-Read** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Quiz me on **News Feed: Fan-out-on-Write vs Fan-out-on-Read** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Help me remember **News Feed: Fan-out-on-Write vs Fan-out-on-Read** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.