News feed generation in HLD - System Design Exercise

Design: News Feed Generation System

Design covers feed generation, storage, and retrieval. Does not cover user authentication or content moderation.

Functional Requirements

FR1: Users can follow other users and see their posts in a personalized feed

FR2: Feed should show posts sorted by recency and relevance

FR3: Support 10 million active users with 1 million new posts per day

FR4: Feed updates should appear within 5 seconds of new posts

FR5: Users can like and comment on posts

FR6: Support pagination and infinite scrolling in the feed

FR7: Allow filtering feed by topics or hashtags

Non-Functional Requirements

NFR1: System must handle 100,000 concurrent feed requests

NFR2: API response time for feed retrieval should be under 200ms (p99)

NFR3: System availability should be 99.9% uptime

NFR4: Data consistency for likes and comments must be strong

NFR5: Storage should be scalable for growing user and post data

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

User service to manage follow relationships

Post storage database

Feed generation service (push or pull model)

Cache layer for fast feed retrieval

Ranking and personalization engine

API gateway for client requests

Design Patterns

Fan-out on write vs fan-out on read

Caching strategies (e.g., Redis, Memcached)

Message queues for asynchronous processing

Sharding and partitioning for scalability

Event-driven architecture for updates

Reference Architecture

Client
  |
  v
API Gateway
  |
  v
Feed Service <--> User Service
  |               |
  |               v
  |           Follow DB
  |
  v
Cache (Redis)
  |
  v
Post Storage (NoSQL DB)
  |
  v
Message Queue --> Feed Generator Worker
  |
  v
Ranking Engine

Components

API Gateway

Nginx or AWS API Gateway

Handles client requests, routes to feed service

Feed Service

Node.js/Java microservice

Handles feed retrieval, pagination, filtering

User Service

Java/Spring Boot

Manages user data and follow relationships

Follow DB

Relational DB (PostgreSQL)

Stores user follow relationships

Cache

Redis

Stores precomputed feeds for fast retrieval

Post Storage

NoSQL DB (Cassandra or DynamoDB)

Stores posts and metadata

Message Queue

Kafka or RabbitMQ

Queues new posts for feed generation

Feed Generator Worker

Python/Java worker

Processes new posts, pushes updates to followers' feeds

Ranking Engine

Custom service or ML model

Ranks posts by relevance and recency

Request Flow

1. User posts new content via API Gateway

2. Post stored in Post Storage

3. Post event sent to Message Queue

4. Feed Generator Worker consumes event, fetches followers from Follow DB

5. Worker pushes post to followers' feed cache in Redis

6. User requests feed via API Gateway

7. Feed Service fetches feed from Redis cache

8. Ranking Engine adjusts order based on relevance

9. Feed Service returns sorted feed to user

Database Schema

Entities: - User(user_id PK, name, ...) - Follow(follower_id FK->User, followee_id FK->User, PK(follower_id, followee_id)) - Post(post_id PK, user_id FK->User, content, timestamp, topics) - Like(user_id FK->User, post_id FK->Post, PK(user_id, post_id)) - Comment(comment_id PK, post_id FK->Post, user_id FK->User, content, timestamp) Relationships: - User to Follow is 1:N (one user can follow many users) - User to Post is 1:N - Post to Like is 1:N - Post to Comment is 1:N

Scaling Discussion

Bottlenecks

Feed cache size grows too large for Redis memory

Message queue overwhelmed by high post volume

Ranking engine latency increases with feed size

Database hotspots on popular users or posts

API Gateway throttling under heavy concurrent requests

Solutions

Shard Redis cache by user ID or region; use eviction policies

Partition message queue topics; scale consumers horizontally

Use approximate ranking or pre-rank feeds offline

Use database sharding and read replicas

Use load balancers and autoscaling for API Gateway

Interview Tips

Time: 10 min for requirements and clarifications, 15 min for architecture and components, 10 min for data flow and database design, 10 min for scaling and trade-offs discussion

Clarify real-time vs batch feed generation trade-offs

Explain fan-out on write vs fan-out on read

Discuss caching strategies and cache invalidation

Describe how to handle large scale with sharding and partitioning

Mention consistency needs for likes and comments

Highlight how ranking improves user experience

Practice

1. What is the main purpose of a news feed generation system in social media platforms?

easy

A. To store user passwords securely

B. To manage user account settings

C. To show personalized and timely content to users

D. To handle payment transactions

Solution

1. Step 1: Understand the role of news feed generation

   The news feed system is designed to deliver content that is relevant and timely to each user.

2. Step 2: Identify the correct purpose among options

   The other options relate to security, settings, and payments, which are unrelated to news feed generation.

3. Final Answer:

   To show personalized and timely content to users -> Option C

4. Quick Check:

   News feed = personalized timely content [OK]

Hint: News feed = personalized content display [OK]

Common Mistakes:

• Confusing news feed with user authentication
• Mixing news feed with payment processing
• Thinking news feed manages account settings

2. Which of the following is a common method used in news feed generation to deliver updates efficiently?

easy

A. Manual refresh by users only

B. Push model where updates are sent to users proactively

C. Storing all data in a single database without caching

D. Using FTP to transfer news feed data

Solution

1. Step 1: Identify common delivery methods in news feed systems

   Push model proactively sends updates to users, improving latency and experience.

2. Step 2: Evaluate other options for efficiency

   Manual refresh is user-driven and less efficient; no caching slows performance; FTP is unrelated to real-time feed delivery.

3. Final Answer:

   Push model where updates are sent to users proactively -> Option B

4. Quick Check:

   Push model = efficient update delivery [OK]

Hint: Push model proactively sends updates [OK]

Common Mistakes:

• Assuming manual refresh is efficient
• Ignoring caching benefits
• Confusing FTP with real-time data delivery

3. Consider a news feed system using a pull model where users request their feed on demand. What is a likely outcome when many users request feeds simultaneously?

medium

A. Users receive outdated feeds only

B. Instant delivery with no server load

C. System automatically caches all feeds without delay

D. High latency and increased load on backend servers

Solution

1. Step 1: Understand pull model behavior under load

   Pull model requires backend to generate feeds on request, causing high load if many users request simultaneously.

2. Step 2: Analyze other options for feasibility

   Instant delivery with no load is unrealistic; outdated feeds depend on caching, not pull model alone; automatic caching without delay is ideal but not guaranteed.

3. Final Answer:

   High latency and increased load on backend servers -> Option D

4. Quick Check:

   Pull model + many requests = high load [OK]

Hint: Pull model causes backend load spikes [OK]

Common Mistakes:

• Assuming pull model has no latency
• Confusing caching with pull model behavior
• Believing feeds are always instantly cached

4. A news feed system uses a push model but users report seeing stale content. Which is the most likely cause?

medium

A. Cache not invalidated after new content is pushed

B. Users are not refreshing their browsers

C. Backend servers are down

D. Users have slow internet connections

Solution

1. Step 1: Identify push model behavior and caching role

   Push model sends updates, but if cache is not invalidated, users see old content.

2. Step 2: Evaluate other options for staleness cause

   Browser refresh is less relevant in push; backend down causes no updates; slow internet delays but does not cause stale cached data.

3. Final Answer:

   Cache not invalidated after new content is pushed -> Option A

4. Quick Check:

   Push + stale feed = cache invalidation issue [OK]

Hint: Stale feed often means cache invalidation failed [OK]

Common Mistakes:

• Blaming user refresh instead of cache
• Ignoring cache invalidation importance
• Assuming slow internet causes stale cache

5. You are designing a news feed system for a platform with 100 million users. Which approach best balances scalability and freshness of content?

hard

A. Hybrid model: push important updates and pull less critical content

B. Pure pull model: generate feed on every user request

C. Pure push model: push all updates to all users immediately

D. No caching: always fetch fresh data from database

Solution

1. Step 1: Analyze scalability and freshness needs for large user base

   Pure pull causes high load; pure push is costly and complex; no caching is inefficient.

2. Step 2: Evaluate hybrid model benefits

   Hybrid model pushes critical updates for freshness and uses pull for less urgent content, balancing load and latency.

3. Final Answer:

   Hybrid model: push important updates and pull less critical content -> Option A

4. Quick Check:

   Hybrid model balances scale and freshness [OK]

Hint: Hybrid push-pull balances scale and freshness [OK]

Common Mistakes:

• Choosing pure pull causing backend overload
• Choosing pure push causing network overload
• Ignoring caching and load balancing