Designing a News Feed System Design — Fanout-on-Write vs Fanout-on-Read

Designing a news feed system design answer is mostly about one tradeoff: fanout-on-write vs fanout-on-read. A feed looks simple to users — open the app and see recent, relevant posts — but the backend has to handle writes from creators, reads from followers, ranking, privacy, media, notifications, and hot accounts with millions of followers. The interview is not testing whether you can name every distributed system component. It is testing whether you can choose where work happens, explain the bottlenecks, and adjust the design when scale or product requirements change.

Designing a news feed system design: requirements first

Start by pinning down product behavior. A clean requirement statement might be:

• Users can create posts with text, images, or links.
• Users can follow other users.
• The home feed shows posts from followed users, ranked by freshness and relevance.
• Feed reads should be fast, ideally under a few hundred milliseconds.
• Posts must respect blocks, privacy settings, deleted content, and muted authors.
• The system should support high fanout accounts without slowing normal users.

Then ask scale questions. How many daily active users? Average follows per user? Posts per day? Feed reads per day? Celebrity accounts? Required freshness? Is ranking chronological or ML-ranked? Do we need exactly-once delivery? Most feeds do not require perfect exactness. They require low latency, high availability, and eventual correctness.

A useful back-of-envelope example: 100 million daily users, 20 feed reads per user per day, 2 billion feed reads daily. If each feed read hits databases heavily, the design fails. Feed reads dominate. That points toward caching and precomputation.

The core data model

Keep the initial model simple:

| Entity | Key fields | |---|---| | User | user_id, profile, privacy settings | | Follow edge | follower_id, followee_id, created_at | | Post | post_id, author_id, body/media pointers, created_at, visibility, deletion status | | Timeline item | user_id, post_id, author_id, score/time, inserted_at | | Engagement | user_id, post_id, action, timestamp |

Posts live in a durable post store. Follow edges live in a graph or relational store optimized for follower/followee lookups. Timelines live in a fast store, often a key-value or wide-column store keyed by user id with sorted items. Media lives in object storage plus CDN. Ranking features may live in separate feature stores or caches.

Separate the post object from the feed reference. A timeline item usually stores post_id, author_id, score, and timestamp, not the entire post body. On read, hydrate post details in batch. This avoids rewriting millions of timeline items when a post is edited or deleted.

Fanout-on-write

Fanout-on-write means that when Alice publishes a post, the system immediately pushes a reference to that post into the home timelines of Alice's followers. If Alice has 500 followers, write 500 timeline items. When Bob opens his feed later, the system reads his precomputed timeline quickly.

The flow:

1. Alice creates a post.
2. Post service validates and stores the post.
3. A message is published to a fanout queue.
4. Fanout workers fetch Alice's followers in batches.
5. Workers insert timeline references into each follower's home timeline.
6. Feed reads fetch precomputed timeline items and hydrate posts.

The benefit is read speed. The cost is write amplification. One post can create thousands or millions of timeline writes. For ordinary users this is fine. For celebrities, it is expensive and may create lag.

Fanout-on-write is strong when reads are much more common than writes, freshness matters, and most authors have moderate follower counts. That describes many social feeds. It also creates simple read paths, which is valuable because feed reads are the hot path.

Fanout-on-read

Fanout-on-read means the system does not precompute each follower timeline when a post is created. Instead, when Bob opens the app, the system finds the people Bob follows, fetches their recent posts, merges and ranks them, then returns the feed.

The flow:

1. Bob requests home feed.
2. Feed service loads Bob's followees.
3. It fetches recent posts from those authors.
4. It merges candidates by time or score.
5. It filters privacy, mutes, blocks, and deleted content.
6. It returns hydrated feed items.

The benefit is cheap writes and always-fresh relationship logic. If Bob follows Alice now, her recent posts can appear immediately without backfilling. The cost is read-time work. If Bob follows 2,000 people and opens the feed frequently, this gets expensive fast.

Fanout-on-read is strong when users follow a small number of sources, writes are heavy, reads are less frequent, or correctness depends on complex read-time rules. It is also useful for celebrity accounts because you avoid pushing one post into millions of timelines.

The comparison that interviewers expect

| Dimension | Fanout-on-write | Fanout-on-read | |---|---|---| | Write cost | High for authors with many followers | Low | | Read latency | Low, timeline precomputed | Higher, must gather and merge | | Freshness | Good but fanout may lag | Good at read time | | Celebrity accounts | Hard without special handling | Easier | | Storage | More timeline copies | Fewer copies | | Ranking | Can pre-rank partially | Can rank with latest features | | Follow/unfollow changes | Requires backfill or filtering | Naturally reflected |

A senior answer does not pick one blindly. It proposes a hybrid.

Hybrid timeline design

A practical feed usually uses fanout-on-write for normal authors and fanout-on-read for high-follower authors. Set a threshold: if an author has fewer than, say, 100,000 followers, push the post to follower timelines. If the author is above the threshold, store the post in the author's outbox and merge it at read time for followers.

Read path for Bob:

1. Fetch Bob's precomputed home timeline from timeline store.
2. Fetch recent posts from high-follower accounts Bob follows.
3. Fetch promoted, recommended, or group content if product requires it.
4. Merge candidates.
5. Apply visibility filters.
6. Rank candidates.
7. Hydrate post/media/user details.
8. Return page plus cursor.

This gives normal users fast feed reads while preventing celebrity writes from overwhelming the system. It also makes ranking more flexible because high-impact posts can be mixed in with fresh scoring.

The threshold is not fixed. It depends on follower count, post frequency, worker capacity, read frequency of followers, and freshness SLA. A creator with 5 million followers who posts once a month may be cheaper than a creator with 300,000 followers who posts 200 times a day.

Ranking and candidate generation

Chronological feed is easier: sort by time, apply filters, paginate. Ranked feed needs candidate generation and scoring. Candidate sources might include:

• Precomputed followed-author timeline
• Celebrity outbox posts
• Reshares or replies from followed users
• Recommended posts from similar interests
• Ads or promoted items
• Local/trending content

Ranking features might include author affinity, post age, engagement velocity, media type, prior clicks, hides, reports, and relationship strength. In an interview, do not pretend to design the entire ML platform. Say the feed service calls a ranking service with a candidate batch and user context, then caches ranked pages or top candidate ids where appropriate.

Freshness vs relevance is a product choice. A breaking-news product may heavily weight recency. A professional network may weight relationship and quality. The backend design should support both by keeping candidate generation separate from ranking.

Storage and caching

A feed design lives or dies on caching. Common layers:

• Post cache: batch get recent post objects by id.
• Timeline cache: store the first page or top N timeline item ids per user.
• User/profile cache: avoid repeated profile lookups during hydration.
• Media CDN: serve images/videos outside the feed service.
• Feature cache: store precomputed ranking features for hot users and posts.

For timeline storage, a wide-column store or sorted key-value structure works well: key by user id, sort by time or score, keep the most recent N items. You do not need infinite history in the hot timeline. Older pages can fall back to slower stores or archive paths.

For write fanout, use queues and idempotent workers. If a worker retries, inserting the same (user_id, post_id) should not duplicate feed items. Include dedupe keys. Track fanout progress for large authors. Use dead-letter queues for poison messages.

Privacy, deletion, and correctness

Feed systems fail interviews when candidates ignore privacy. A timeline item can be stale. A user may unfollow, block, mute, or lose permission after a post was pushed. Therefore read-time filtering is still required even with fanout-on-write.

Rules to call out:

• Deleted posts should disappear quickly. Store deletion state on the post and filter at hydration; optionally remove timeline references asynchronously.
• Blocks should be enforced at read time, not only at write time.
• Private account posts should only show to approved followers.
• Mutes and hides are per-viewer and belong in read-time filters.
• Edits should update the post object, not every timeline reference.

This is why fanout-on-write is precomputation, not final truth. The final answer is produced on read after filters.

Pagination and consistency

Cursor-based pagination is safer than offset pagination. A cursor can include timestamp/score and a tie-breaker post id. Offset pagination performs badly and behaves oddly when new posts arrive.

For ranked feeds, pagination is trickier because scores can change between requests. Common approaches include caching a ranked session for a short period or using a cursor that anchors the candidate set. In an interview, say that the first page is optimized most aggressively because it receives the most traffic. Later pages can tolerate slightly higher latency.

Consistency can be eventual. If Alice posts and Bob sees it after a few seconds, most products are fine. For notifications or direct mentions, use a separate path with stronger freshness.

Common traps in news feed system design

Ignoring celebrity users. Pure fanout-on-write collapses on accounts with massive follower counts.

Making reads too expensive. Pure fanout-on-read can require thousands of author lookups per feed open.

Storing full posts in timelines. This creates update and deletion pain.

Forgetting privacy. Precomputed timelines still need read-time filters.

No backpressure. Fanout workers need queues, rate limits, retries, and monitoring.

Over-designing ML. Ranking matters, but the core system tradeoff is candidate generation and fanout strategy.

Weak pagination. Offset pagination is not a good fit for constantly changing feeds.

Interview answer structure

Use this flow:

1. Clarify requirements and scale.
2. Define APIs: create post, follow user, get feed.
3. Sketch data model: users, follows, posts, timeline items.
4. Explain fanout-on-write.
5. Explain fanout-on-read.
6. Propose hybrid with celebrity threshold.
7. Detail read path, write path, caching, ranking, and privacy.
8. Discuss failure modes and tradeoffs.

A strong closing statement: "I would optimize the normal feed read path with precomputed timelines, but I would not fan out high-follower accounts on write. Those posts stay in an author outbox and are merged at read time. The final read still applies privacy and ranking, so precomputation speeds up the path without becoming the source of truth."

How to describe this skill on a resume

For interview prep, the value is being able to explain tradeoffs. For a resume, tie the pattern to real systems:

• "Designed event-driven fanout pipeline that precomputed user-specific notification feeds while preserving read-time permission checks."
• "Reduced feed latency by separating candidate generation from ranking and caching first-page timeline ids."
• "Built idempotent queue workers for high-volume timeline updates with retry and dedupe controls."

The system design lesson is broader than social media. Any product with personalized streams — alerts, inboxes, recommendations, activity logs, jobs, transactions — has the same question. Do you push work at write time, pull at read time, or mix both? Answer that cleanly and the design becomes much easier to defend.

Related guides

• Caching Strategies for System Design Interviews: Write-Through, Write-Back, and TTL Patterns — The caching section of a FAANG system design loop is where mediocre candidates blur together. Here's how to name tradeoffs, pick a pattern on purpose, and survive the hot-key follow-up.
• Designing a Chat System Design Interview — WebSockets, Presence, and Message Storage — A system design interview guide for chat applications, covering WebSockets, fanout, message ordering, presence, storage, delivery receipts, media, search, scaling, and common trade-offs.
• Designing a Payment System Design Interview — Idempotency, Ledgers, and Reconciliation — A senior payment-system design answer lives or dies on idempotency, double-entry ledgers, and reconciliation. This guide gives the architecture, state model, failure-mode answers, and interview script.
• Designing a Rate Limiter System Design — Distributed Counters and Consistency — A system design interview guide for rate limiters: choose token buckets or sliding windows, design distributed counters, handle multi-region consistency, and plan failure behavior.
• Designing a Search System Design Interview — Inverted Index, Ranking, and Recall — A practical system design guide for search interviews, covering inverted indexes, crawling and ingestion, query execution, ranking, recall, freshness, personalization, scaling, and evaluation trade-offs.