Fan-out on write vs fan-out on read

The two approaches

Why fan-out on write breaks at the top

An account with ten million followers generates ten million inserts per post. At any meaningful posting rate that is a write storm that dominates the cluster, and the latency of the author's own publish becomes unacceptable if it waits for completion. Doing it asynchronously helps the author but does not reduce the work - and during a spike the backlog means some followers see the post minutes late, which is its own product problem.

The hybrid, which is what large systems actually run

• Normal accounts: fan-out on write. Cheap, because almost everyone has a small follower count, and it keeps reads fast for the common case.
• Large accounts: fan-out on read. Their posts are not pushed. At read time, the reader's pre-built feed is merged with a live query for the handful of large accounts they follow.
• The threshold is operational, tuned to where write amplification starts to hurt - not a principled constant.
• Merging is the complexity cost. Two sources means ranking and deduplicating at read time, so the read path is no longer a single lookup.

Details that come up as follow-ups

• Inactive users. Pushing to accounts that have not opened the app in months is wasted write and storage. Common fix: skip inactive followers and backfill on their next login.
• Deletes and edits. With fan-out on write the post exists in millions of places. Usually resolved by storing only a post ID in feeds and resolving content at read time - which quietly reintroduces a read-time join.
• Ranking. A chronological feed is a merge; a ranked feed needs features and a model at read time, which pushes designs back toward pull.
• Backfill. A new follow should populate history, which is a bulk operation that needs rate-limiting of its own.

How to answer this in an interview

State both approaches and their asymmetry, then immediately ask about the follower distribution and the read-to-write ratio, because those two numbers decide it. Proposing the hybrid without first establishing the skew reads as recalled rather than reasoned. Related designs are in design a news feed and design a notification system.

Where CoPilot Interview fits

Disclosure: we build an interview assistant, so treat this as a disclosed pitch. CoPilot Interview is a native Windows and macOS app that puts suggested answers on your own screen in about two seconds, across coding, system design and behavioral rounds, with a permanent free tier that needs no credit card.

Frequently asked questions

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

Fan-out on write inserts a post into every follower's pre-built feed, making reads a single cheap lookup and writes O(followers). Fan-out on read writes once and assembles the feed by querying all followees at read time, making writes cheap and reads more expensive.

Why does fan-out on write break for large accounts?

An account with millions of followers generates millions of inserts per post, which dominates write capacity and causes backlogs where some followers receive the post minutes late. Doing the fan-out asynchronously protects the author's publish latency but does not reduce the total work.

What does a hybrid feed design look like?

Fan-out on write for ordinary accounts, since the follower distribution is heavily skewed toward small counts, combined with fan-out on read for a small number of very large accounts whose posts are merged into the feed at query time. The threshold is tuned operationally rather than being a principled constant.

How do you handle deletes with fan-out on write?

Store only post IDs in each follower's feed and resolve content at read time, so a delete or edit affects one record rather than millions of copies. The trade-off is that the read path regains a join, which partly erodes the reason for pre-computing feeds.