Fan-out on write and on read for system design

How it works

Start with a source of truth: store each post once, indexed by author and publication order. Fan-out usually distributes post IDs into recipient timelines, not copies of the full post or media.

With fan-out on write, publishing creates durable background work. Workers enumerate followers and insert the post ID into each follower’s bounded home timeline. An author with 500 eligible followers causes up to 500 timeline insertions; reading a home feed then starts with one prepared list.

With fan-out on read, publishing only updates the author’s post list. When a reader opens their feed, the service retrieves recent candidates from followed authors and merges them. A reader following 300 authors may require candidates from 300 author lists, although batching and caching can reduce network calls.

A hybrid approach pushes ordinary authors’ posts into recipient timelines but pulls high-fan-out authors’ posts at read time. The reader’s prepared timeline is merged with those additional candidates, deduplicated, and ordered or ranked. The cutoff should reflect posting frequency, audience activity, worker capacity, and read latency, not just follower count.

Prepared timelines are derived data, so asynchronous updates can lag. Use a durable publication-to-worker handoff, retry-safe inserts keyed by recipient and post, and explicit handling for follow changes and deletions. Before returning content, enforce current visibility rules; a stale timeline entry must not bypass a block or privacy change.

A worked example

A hybrid home feed with a large-audience author

Suppose ordinary authors publish 100 posts per second, each with 200 eligible active followers on average. Write fan-out produces about 20,000 timeline insertions per second, before retries and replication. Now an author with 5 million followers publishes: pushing that single post creates up to 5 million additional insertions. Instead, keep that author on the pull path. When a reader opens the feed, fetch their prepared timeline and recent posts from the large-audience authors they follow, then merge and deduplicate the candidates. Bound each source’s candidate window and batch content retrieval. Monitor queue age and feed-read latency to decide whether the split still fits the workload.

Trade-offs to say out loud

Read latency versus write amplification: Write fan-out makes reads simpler but creates work proportional to eligible recipients, while read fan-out shifts candidate retrieval and merging onto feed requests.
Audience activity: Precomputing feeds for inactive users can waste writes and storage, so active-user fan-out with a rebuild path may be cheaper.
Skew and burst capacity: A single popular author can create a huge write backlog, while read fan-out can overload hot author lists or readers who follow many accounts.
Freshness and failure recovery: Asynchronous write fan-out introduces delivery lag and replay work, while read fan-out avoids that particular lag but still depends on source and cache freshness.
Storage and retention: Per-recipient timelines duplicate references and need retention limits, whereas read fan-out stores fewer derived entries but repeatedly assembles results.
Hybrid complexity: Combining pushed and pulled candidates adds deduplication, pagination, and transition logic when an author changes delivery modes.

When to reach for it

You are designing a social home feed where one publication may appear in many personalized timelines.
Feed reads greatly outnumber publications, and the latency target makes precomputed recipient timelines attractive.
Follower counts or group sizes vary widely, so one delivery strategy would perform poorly for the largest audiences.
Many recipients rarely read, making the cost of preparing every recipient’s view worth questioning.
A group-messaging design must choose between per-recipient inbox entries and a shared message history that members read using cursors.

How to bring it up in the interview

Define what you are distributing: post IDs in a derived timeline, full messages in inboxes, or live network events. Feed materialization and WebSocket delivery are separate decisions.
Estimate both sides: publication rate times eligible recipient count for write fan-out, and feed-read rate times candidate sources for read fan-out. Include skew and burst sizes rather than relying only on averages.
Propose a baseline before a hybrid: explain why the expected read volume, audience activity, and latency target favor one approach, then identify the workload that breaks it.
Expect probes about worker crashes and celebrity posts. Explain durable handoff, idempotent insertion, chunked fan-out tasks, queue age, and how you keep a large publication from delaying unrelated work.
Defend the read path too: bound candidate retrieval, define stable pagination, and explain deletion and authorization checks across stale or partially populated timelines.

Common mistakes

Saying write fan-out makes publishing synchronously wait for every follower; it is usually background work after durable acceptance.
Calling read fan-out cheap without accounting for readers who follow thousands of authors and the tail latency of fetching their candidates.
Choosing a universal celebrity threshold without considering posting rate, active followers, available capacity, and read demand.
Treating a prepared timeline as the source of truth or assuming eventual cleanup is sufficient for privacy revocation.
Ignoring retries, duplicate entries, partial fan-out, and pagination when merging pushed and pulled posts.

Where it comes up

Interview questions where fan-out on write and on read is part of a strong answer, and why.

Questions people ask

What is the difference between fan-out on write and fan-out on read?

Fan-out on write updates recipient-specific views when content is published, usually through background workers. Fan-out on read retrieves content from multiple sources and assembles the recipient’s view when requested. The main trade-off is precomputed writes and storage versus read-time work and latency.

Why use a hybrid fan-out strategy for a news feed?

Write fan-out works well when preparing recipient timelines is affordable and saves repeated read work. Very large or frequently posting authors can make that preparation expensive, so their posts can be fetched at read time instead. A hybrid limits write bursts but adds merging, deduplication, and pagination complexity.

Is fan-out on write strongly consistent?

Not inherently. When background workers populate timelines, a post can be durably stored before all recipients can see it. Define a freshness target and, if needed, provide read-your-writes behavior by merging the author’s recent posts into their own feed.