News feed generation in HLD - Scalability & System Analysis

Scalability Analysis - News feed generation

Growth Table: News Feed Generation

Scale	Users	Feed Requests/Second	Data Volume	Latency Expectation	System Changes
Small	100	10-50	MBs of posts	< 1s	Single server, simple DB queries
Medium	10,000	1,000-5,000	GBs of posts	< 500ms	DB indexing, caching, load balancer
Large	1,000,000	50,000-100,000	TBs of posts	< 300ms	Feed pre-generation, sharded DB, distributed cache
Very Large	100,000,000	5,000,000+	Petabytes of posts	< 200ms	Massive horizontal scaling, CDN, microservices, data partitioning

First Bottleneck

At small scale, the database query speed limits feed generation because fetching and sorting posts for each user is slow.

At medium scale, the database CPU and I/O become bottlenecks due to many concurrent feed requests.

At large scale, network bandwidth and cache invalidation delays cause latency issues.

Scaling Solutions

• Database Optimization: Add indexes, use read replicas to distribute read load.
• Caching: Use in-memory caches (e.g., Redis) to store popular feeds or feed fragments.
• Feed Pre-generation: Generate feeds offline and store them for quick retrieval.
• Sharding: Partition user data across multiple databases to reduce load per instance.
• Horizontal Scaling: Add more application servers behind load balancers.
• Content Delivery Network (CDN): Cache static content and reduce latency globally.
• Microservices: Separate feed generation, user service, and post service for better scalability.

Back-of-Envelope Cost Analysis

• At 1M users with 100K feed requests/sec, assuming each feed request reads 50 posts (~10KB each), total data read = 100K * 50 * 10KB = ~50GB/s.
• Storage needed for posts: If each user generates 10 posts/day, 1M users produce 10M posts/day (~100GB/day assuming 10KB/post).
• Network bandwidth: 50GB/s read traffic requires multiple 10Gbps network links.
• CPU: Multiple servers needed to handle sorting and merging posts per feed request.

Interview Tip

Start by explaining the user scale and traffic. Identify the main bottleneck (usually DB). Discuss caching and pre-generation to reduce load. Mention sharding and horizontal scaling for large scale. Always justify why each solution fits the bottleneck.

Self Check

Your database handles 1000 QPS. Traffic grows 10x to 10,000 QPS. What do you do first?

Answer: Add read replicas and implement caching to reduce direct DB load before scaling application servers.

Key Result

News feed generation first breaks at the database due to heavy read and sorting load; caching and feed pre-generation are key to scaling efficiently.

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