Fan-out Architecture for News Feed Systems

Welcome back! In our last session, we designed a scalable chat application, where you saw how a publish/subscribe system could "fan out" messages to manage group chats. This concept of delivering a single piece of information to many recipients is a fundamental pattern in distributed systems.

Today, we'll explore this pattern in much greater depth by tackling another quintessential system design interview problem: designing a news feed system. Our goal is to design a system that employs a fan-out architecture for message distribution. This is a crucial topic for your goal of mastering scalable systems, as it forces a direct confrontation with one of the most classic trade-offs in the field: optimizing for writes versus optimizing for reads. We will dissect the strategies used by giants like Twitter and Facebook to serve billions of feeds daily.

Step 1: Defining the Scope

As you prepare for senior-level interviews, you know that the first step is always to clarify the problem. A news feed can be incredibly complex, with algorithmic ranking, ads, and various content types. To make this tractable for a one-hour session, we'll focus on the core functionality.

Based on this, let's establish our requirements:

• Functional Requirements:

  1. A user can publish a post.
  2. A user can follow other users.
  3. A user can see a news feed containing posts from the people they follow.
  4. The feed should be sorted in reverse chronological order (newest first).

• Non-Functional Requirements:

  1. Low Latency on Read: Viewing the news feed should be very fast, ideally under a few hundred milliseconds.
  2. High Availability: The system must be resilient to failures.
  3. Eventual Consistency: It's acceptable if a new post takes a short time (e.g., up to a minute) to appear in all followers' feeds.

With these requirements, the central challenge becomes clear: how do we efficiently deliver a post from one user to potentially millions of followers while keeping feed retrieval fast?

Step 2: The Fundamental Trade-Off: Push vs. Pull

At the heart of any news feed design lies a choice between two architectural models for distributing content. This is often framed as "fan-out on write" vs. "fan-out on read".

• Fan-out on Write (Push Model): When a user creates a post, the system immediately "pushes" that post (or a reference to it) into the feed of every single follower. The work is done at write time. This means each follower's feed is pre-computed and ready to be served.
• Fan-out on Read (Pull Model): When a user wants to see their feed, the system "pulls" the latest posts from all the people they follow, merges them, sorts them, and then presents the result. The work is done at read time.

Your experience with small-scale systems likely involved the pull model, as it's simpler to implement when the number of followed accounts is small. However, at scale, the choice has massive implications for performance and cost.

As you can see from the reading, the choice is not simple:

• The Push model optimizes for fast reads but creates enormous write amplification.
• The Pull model optimizes for simple writes but makes reads slow and computationally expensive.

Step 3: The Push Model in Detail: Fan-out on Write

Let's design a system based on the fan-out-on-write (push) model, as our primary non-functional requirement is low latency on reads. This architecture prioritizes the user experience of scrolling the feed.

The high-level flow when a user creates a post looks like this:

Let's break down this asynchronous process. Because you've worked with Go and have an interest in resilient systems, think of this as a set of interacting goroutines or microservices communicating via a message broker like RabbitMQ or Kafka.

This asynchronous fan-out is the core of the architecture. The key components are:

1. Post Service: Receives the new post, stores it in a Post DB, and publishes a post_created event to a message queue.
2. Message Queue: Decouples the write path from the fan-out logic, ensuring that even if fan-out is slow, the user who posted gets a fast response.
3. Fan-out Workers: A pool of services that consume events from the queue. For each post_created event, a worker:
   a. Retrieves the author's follower list from a User/Social Graph DB.
   b. For each follower, it inserts the post_id into their respective feed list in a News Feed Cache. A system like Redis is ideal here, where each user's feed can be a list or sorted set keyed by user_id.

When a user requests their feed, the Feed Service simply reads the list of post_ids from the News Feed Cache for that user, a very fast operation.

Step 4: The Celebrity Problem and the Hybrid Solution

The pure fan-out-on-write model has a glaring weakness, often called the "celebrity problem" or "hot publisher problem." What happens when a user with 50 million followers posts? Your fan-out workers suddenly have to perform 50 million writes to the News Feed Cache. This can create a massive "thundering herd" of activity that can overwhelm your cache, database, and network.

This is where the industry-standard hybrid model comes in.

The hybrid approach elegantly solves the problem:

• For most users (e.g., those with < 10,000 followers), continue using the fan-out-on-write (push) model.
• For "celebrity" users (those with a very high follower count), do not fan out their posts on write. Instead, treat them as a special case.

When a user requests their feed, the process becomes:

1. Fetch the pre-computed feed of post_ids from their News Feed Cache (this contains posts from all the non-celebrities they follow).
2. Identify the list of celebrities the user follows.
3. Fetch the most recent posts directly from those celebrities (a fan-out-on-read/pull operation).
4. Merge the two lists of posts in the Feed Service, sort chronologically, and return the result.

This hybrid model contains the write storm from celebrities while still providing the low-latency read benefits of the push model for the vast majority of user interactions.

Step 5: The Read Path and Feed Hydration

So far, we've only discussed lists of post_ids. A client application needs much more: the post content, author's name and profile picture, like/comment counts, etc. The process of fetching this full data is called hydration.

The read path for our hybrid system looks like this:

As the resource describes, the News Feed Service acts as an aggregator on the read path. It:

1. Retrieves the list of post_ids (after merging celebrity and non-celebrity posts).
2. For each post_id, it fetches the full post data from a Post Cache (falling back to the Post DB).
3. For each post's author_id, it fetches the user data from a User Cache (falling back to the User DB).
4. It assembles the final JSON response and sends it to the client.

Extensive caching at each layer (News Feed Cache, Post Cache, User Cache) is absolutely critical to meeting our low-latency requirement.

Conclusion

In this lesson, you designed a scalable news feed system by navigating the critical trade-offs of a fan-out architecture. This problem beautifully illustrates the challenges you'll face when moving from small-scale applications to systems that serve millions.

Key Takeaways:

• Central Trade-off: News feed design is a classic battle between fan-out-on-write (push) for fast reads and fan-out-on-read (pull) for simple writes.
• The Celebrity Problem: A pure fan-out-on-write model creates massive write spikes for popular users, a major bottleneck at scale.
• The Hybrid Solution: The industry-standard solution is a hybrid model. Use the push model for the majority of users and switch to the pull model for celebrities. This balances read performance with write-path stability.
• Asynchronous Processing: Using message queues and background workers is essential for a resilient and scalable write path, decoupling the user-facing action from the heavy lifting of the fan-out.
• Hydration and Caching: The read path involves not just fetching post IDs but also "hydrating" them with full content, a process that relies heavily on a multi-layered caching strategy to remain fast.

You have now designed two of the most common systems asked about in interviews: a chat application and a news feed. In our final lesson, we will focus on how to synthesize and articulate these complex designs using a structured framework, preparing you to confidently present your architectural vision in a high-stakes interview.