Designing a Social Media Feed System

1. Scoping the Problem: Requirements and High-Level Flows

As with any system design interview, the first step is to clarify the scope. A "social media feed" can be incredibly complex, so we need to agree on a core set of features with the interviewer.

Based on this, let's establish our core requirements for this lesson:

• Functional Requirements:
  • Users can publish posts (e.g., tweets).
  • Users can follow other users.
  • Users can view a news feed on their home page, consisting of a chronologically sorted list of posts from the people they follow.
• Non-Functional Requirements:
  • High Availability: The system must be resilient to failures.
  • Low Latency: Retrieving the news feed must be very fast (e.g., <200ms). This is a read-heavy system. While there are many writes (posts), each post is read by many followers, so read operations far outnumber writes.
  • Scalability: The system must support millions of users.

At a high level, the entire system can be broken down into two main workflows.

To summarize:

1. Feed Publishing (The Write Path): A user creates a post. The system must ingest this post and make it available to all of that user's followers.
2. Feed Retrieval (The Read Path): A user opens their app. The system must generate and display their personalized news feed quickly.

Balancing the performance and complexity of these two paths is the central challenge of this design.

2. High-Level Architecture

With the requirements and core flows defined, we can sketch out the high-level architecture. As an experienced backend engineer, you'll recognize many of these standard components.

This establishes a solid, service-oriented architecture. Let's visualize it.

The key components are:

• Clients: Web and mobile applications that users interact with.
• Load Balancer: Distributes incoming traffic across web servers to prevent any single server from being overwhelmed.
• API Gateway: A single entry point for all client requests. It handles concerns like authentication, rate limiting, and routing requests to the appropriate downstream service. This is a common pattern in microservice architectures.
• Microservices:
  • Post Service: Handles all operations related to creating, editing, and retrieving individual posts (CRUD).
  • User Service (or Profile Service): Manages user profiles, authentication, and the social graph (who follows whom).
  • Feed Service (or Timeline Service): Responsible for generating the personalized news feed for each user. This is the most complex service and the core of our design.

3. API and Data Model Design

Now let's define the contracts (APIs) and the underlying data storage for our key services.

APIs

The two most critical APIs correspond to our main workflows:

1. Feed Publishing API:

   • POST /v1/posts
   • Body: { "content": "This is my first post!", "media_urls": ["..."] }
   • Auth: Requires a user authentication token.
   • The request is handled by the Post Service.

2. Feed Retrieval API:

   • GET /v1/feed
   • Query Params: ?limit=20&cursor=some_opaque_string for pagination.
   • Auth: Requires a user authentication token.
   • The request is handled by the Feed Service.

Data Modeling Decisions

Choosing the right database for the job is a critical skill for a senior engineer. A one-size-fits-all approach won't work for a system with such diverse data types and access patterns.

Let's consolidate these data model designs:

1. Posts/Tweets (Post Service):

   • Storage: A NoSQL Document Store (like MongoDB or AWS DynamoDB).
   • Why?
     • Posts are self-contained documents (a tweet_id, user_id, text, timestamp, media_urls, etc.).
     • The structure can evolve easily (adding new fields like polls or location tags doesn't require a schema migration).
     • There are no complex joins needed to retrieve a single post.
     • They are optimized for high-throughput reads and writes.
   • Example Post document:

     {
       "post_id": "123456789",
       "user_id": "98765",
       "content": "Designing a news feed is fun!",
       "created_at": "2023-10-27T10:00:00Z",
       "media": [
         { "type": "image", "url": "s3_bucket_url/image.jpg" }
       ]
     }
     

   • Media (Images/Videos): Stored in a Blob/Object Store like Amazon S3 or Google Cloud Storage. The database only stores a URL/reference to the media. This is standard practice, as databases are not designed to store large binary files.

2. Users and Social Graph (User Service):

   • User Data: A relational (SQL) database like PostgreSQL or MySQL.
     • Why? User data (username, email, profile info) is highly structured, benefits from the data integrity guarantees of ACID transactions, and often requires complex queries for analytics.
   • Follower Relationships: A Graph Database (like Neo4j or Amazon Neptune).
     • Why? Graph databases are purpose-built to model and query relationships. Answering questions like "Who are the followers of User X?" or "Find mutual friends between User A and User B" is extremely efficient. In a SQL database, this would require complex and slow recursive joins on a self-referencing table, which doesn't scale well.

4. The Core Challenge: Feed Generation

We have our architecture, APIs, and data models. Now we come to the heart of the problem: how does the Feed Service actually construct a user's feed? When a user posts, how do we get that post into their followers' feeds?

This is where you demonstrate senior-level thinking by discussing the trade-offs between two primary approaches.

Let's summarize this crucial trade-off:

1. Fan-out on Read (Pull Model):

   • How it works: When a user requests their feed, the system:
     1. Gets the list of people the user follows from the User Service (Graph DB).
     2. Fetches recent posts for each followed person from the Post Service.
     3. Merges all these posts together and sorts them by time.
   • Pros: The write path is simple—a post is just one write to the Post DB. Inactive users don't consume system resources.
   • Cons: The read path is incredibly slow and expensive. For a user following 500 people, this could mean 500 separate database queries, followed by a large in-memory sort. This fails to meet our low-latency requirement.

2. Fan-out on Write (Push Model):

   • How it works: When a user publishes a post, the system (via an asynchronous process):
     1. Gets the list of all the user's followers.
     2. For each follower, it "pushes" the new post's ID into a pre-computed list representing that follower's feed. This list is often stored in a fast cache like Redis.
   • When a user requests their feed, the system simply reads this pre-computed list of post IDs from the cache, which is extremely fast.
   • Pros: The read path is lightning fast, meeting our latency requirement.
   • Cons: The write path is complex and resource-intensive. A user with a million followers (a "celebrity") would trigger one million writes to the cache, which can overwhelm the system (this is known as the "hotkey" or "celebrity" problem).

As the video suggests, the best solution is a hybrid approach:

• Use fan-out on write for the vast majority of users.
• For celebrities with millions of followers, don't fan out their posts. Instead, when a normal user fetches their feed, merge the posts from their pre-computed feed with the latest posts from any celebrities they follow (a small-scale fan-out on read).

This hybrid model intelligently balances the trade-offs to achieve both fast reads and a manageable write path.

Conclusion

In this lesson, we designed the high-level architecture, APIs, and data model for a social media feed system. You've seen how to break down a large, complex problem into manageable components and, most importantly, how to make and justify critical design decisions.

Key Takeaways:

• Architecture: A microservices approach (Post, User, Feed services) fronted by an API Gateway provides a scalable and maintainable structure.
• Data Modeling: Use the right tool for the job. We chose a NoSQL document store for flexible post data, an object store for media, a relational database for structured user info, and a graph database for efficiently managing follower relationships.
• APIs: Simple, resource-oriented APIs for publishing (POST /v1/posts) and retrieving (GET /v1/feed) are sufficient for our core functionality.
• Core Trade-off: The fundamental challenge is balancing the read and write paths. A hybrid feed generation model (fan-out-on-write for most users, fan-out-on-read for celebrities) provides the best overall solution.

Next Lesson Preview:
The feed generation logic is so critical that it deserves its own deep dive. In our next lesson, we will explore the implementation details of the fan-out-on-write vs. fan-out-on-read strategies, including the role of message queues, caching strategies, and how to handle the "celebrity problem" in more detail.