# Fan-out on write vs Fan-out on read > Fan-out on write precomputes recipients' feeds when a post is published; fan-out on read assembles a reader's feed when requested. Choose write fan-out for predictable, low-latency reads with manageable audience sizes, and read fan-out when precomputing would waste work or create huge write bursts. A hybrid pushes ordinary authors' posts and pulls high-fan-out authors' posts at read time. Source: https://sysround.com/compare/fan-out-on-write-vs-read Updated: 2026-11-05 ## Side by side | | Fan-out on write | Fan-out on read | |---|---|---| | Where work happens | Publish time, usually asynchronously | Feed request time | | Stored feed data | Per-recipient lists of post IDs | Author timelines, with optional result caches | | Publication cost | Grows with eligible recipients | No per-follower feed writes | | Feed read cost | Read a prepared candidate list | Fetch and merge followed authors' candidates | | Main scaling risk | Write amplification and queue backlog | Read amplification and tail latency | | Inactive readers | May receive entries they never read | No feed assembly until they return | | Freshness | Depends on fan-out processing lag | Depends on source and cache freshness | | Deletes and privacy | Invalidate copies; recheck visibility | Filter during assembly; invalidate caches | ## The differences that matter Write fan-out materializes a per-user candidate feed, usually containing post IDs rather than copied post bodies. A durable publication event triggers workers to append those IDs to eligible recipients' feeds. Reading still requires hydration, visibility checks, and possibly ranking, but avoids gathering candidates from every followed author. Read fan-out keeps posts organized by author and gathers candidates from followed authors when a reader opens the feed. Indexed author timelines, batched fetches, bounded candidate windows, and caching can reduce the work. However, users following many active authors can still cause expensive scatter-gather requests and slow tail latency. The useful cost comparison is recipient writes versus repeated candidate retrieval. Estimate write fan-out using the sum of each author's posting rate multiplied by their eligible recipient count. Estimate read fan-out using feed request rate, sources fetched per request, and candidates fetched per source, accounting for cache hits. A global read-to-write ratio alone hides follower skew and inactive users. A hybrid isolates high-fan-out authors: push ordinary posts into recipient feeds, then merge pulled posts from exceptional authors during reads. The cutoff should reflect audience activity, posting frequency, read frequency, and available capacity, not a universal follower count. Deduplicate by post ID and use a consistent ordering or pagination scheme across both sources. Neither approach automatically solves correctness. Write fan-out needs retry-safe inserts, recovery from partial delivery, and a plan for queue lag. Both approaches need explicit behavior for new follows, unfollows, deletes, and privacy changes; stale candidate entries must not bypass current authorization checks. ## Choose Fan-out on write when - Feed reads are frequent, and predictable read latency matters more than minimizing background work. - Most authors have manageable eligible audiences, so recipient writes fit the storage and worker budget. - Many recipients are active enough that precomputed feed entries are likely to be read. - The product tolerates bounded publication-to-feed delay, and workers can recover from bursts through durable queues. ## Choose Fan-out on read when - Authors can reach enormous audiences, making per-recipient publication work too expensive or bursty. - Many followers rarely open the app, so pushing entries to everyone would waste substantial work. - Readers follow a bounded number of sources, and indexed retrieval plus caching can meet the read latency target. - The team wants to avoid per-recipient feed storage and can afford request-time candidate retrieval and merging. ## Worked example: Keep one large author from dominating feed writes Suppose a service receives 100 ordinary posts per second, each targeting 200 eligible followers on average. Pushing them requires about 20,000 recipient-feed inserts per second, before retries and replication. An exceptional author with 5 million eligible followers adds 5 million inserts for a single post. At an assumed spare processing capacity of 100,000 inserts per second, that post alone takes at least 50 seconds to distribute. A hybrid stores that author's post once in their timeline and merges it into followers' feeds when requested. This avoids the publication burst but adds read work, so cache the author's recent candidates and measure merge latency. ## In the interview - Start by defining the feed: chronological or ranked, freshness target, read latency target, retention window, and visibility rules. Push versus pull describes feed computation, not whether the client receives WebSocket updates. - Estimate costs using hypothetical workload inputs, then examine skew. Interviewers will probe the most-followed author, the reader following the most accounts, and bursts rather than just averages. - For write fan-out, explain the durable publication event, partitioned worker tasks, bounded feed storage, and idempotent insertion keyed by recipient and post. Expect questions about retries, partial completion, and backlog recovery. - For read fan-out or a hybrid, explain candidate limits, parallel retrieval, cache misses, deduplication, and stable pagination. Expect follow-ups about what happens when one author timeline is slow or unavailable. - State how deletes, blocks, and private-account changes take effect despite cached candidates. Separate asynchronous cleanup from authorization checks that must protect the current response. ## Common mistakes - Calling push instantaneous or pull strongly consistent. Push has processing lag, while pull can still read stale replicas or caches. - Choosing solely from the read-to-write ratio without considering audience skew, posting rates, recipient activity, or how many authors each reader follows. - Treating write fan-out as copying full posts to every follower, or assuming a prepared candidate list eliminates hydration and ranking work. - Proposing a celebrity hybrid without explaining how the two candidate sources are merged, deduplicated, paginated, and filtered for current visibility. ## Interview questions where it comes up - [Design a news feed like Facebook](https://sysround.com/questions/design-news-feed): The core design choice is whether to materialize recipient feeds, assemble them on demand, or combine both for high-fan-out authors. - [Design Instagram](https://sysround.com/questions/design-instagram): Social photo feeds need a push-versus-pull strategy that handles celebrity publication bursts while preserving visibility checks and stable pagination. - [Design a chat app like WhatsApp](https://sysround.com/questions/design-whatsapp): Large-group history and offline inbox design require deciding whether to write per-member message references or let members read from a shared group log. ## FAQ ### Is fan-out on write the same as a push feed? Yes, in feed architecture, push usually means inserting a post reference into recipients' prepared feeds when the post is published. It does not necessarily mean sending the post to an open client connection. WebSockets, polling, and mobile notifications are separate delivery choices. ### Is fan-out on read better for celebrity accounts? It often is because one publication does not trigger millions of recipient-feed writes. The trade-off is repeated candidate retrieval when followers read their feeds, which caching can reduce. High posting rates and highly active audiences can change the economics, so use workload estimates rather than a fixed follower threshold. ### How does a hybrid push and pull feed work? The read path fetches a user's precomputed feed and recent candidates from followed authors excluded from write fan-out. It merges, deduplicates, checks visibility, and orders or ranks those candidates. Pagination must track a stable boundary or snapshot so changes between requests do not create excessive duplicates or skips. ## Related concepts - [Fan-out on write and on read](https://sysround.com/concepts/fan-out) - [Write amplification](https://sysround.com/concepts/write-amplification) - [Materialized views](https://sysround.com/concepts/materialized-views) - [Message queues](https://sysround.com/concepts/message-queues) - [Eventual consistency](https://sysround.com/concepts/eventual-consistency) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.