DESIGN A NEWS FEED SYSTEM

System design interviews are a pivotal part of technical hiring, especially for software engineers aiming for roles at companies like Meta, Twitter, LinkedIn, or Google. One classic design problem that tests your ability to architect large-scale systems is:

“Design a News Feed System.”

This post offers a deep dive into everything you need to crack this interview, combining core concepts, detailed design discussions, trade-offs, scaling strategies, and real-world applications.


📌 What Is a News Feed System?

A news feed is a dynamically updating list of content posted by a user’s network — typically status updates, photos, videos, and links. Examples include:

  • Facebook’s News Feed
  • Instagram’s Home Feed
  • Twitter’s Timeline

Each of these systems must scale to millions (or billions) of users while maintaining low latency and high availability.


📋 Clarifying Requirements in Interviews

Before you design, ask clarifying questions:

QuestionExample Answer
PlatformWeb and mobile
Content typesText, images, videos
Feed orderingReverse chronological (initially)
Max friends/followers5000
Traffic estimate10 million DAU
Key functionalityCreate posts, view friends’ posts

🧱 Step-by-Step System Design Process

1. Feed Publishing Flow

When a user posts content:

  • A request is sent to POST /v1/me/feed with content and auth_token.
  • The system authenticates the request, persists the post, and distributes it to friends via a fanout strategy.

2. News Feed Retrieval Flow

When a user requests their feed:

  • A request is made to GET /v1/me/feed.
  • The system fetches post IDs from cache and hydrates them with content and user info to return a full feed.

🛠️ Core Components Overview

ComponentDescription
Load BalancerDistributes incoming requests across web servers
Web ServersEnforce auth, rate limits; route requests
Post ServicePersists post in DB and cache
Fanout ServicePushes content to friends’ feeds
Notification ServiceSends real-time alerts to friends
Newsfeed ServiceBuilds and delivers the feed to users
Newsfeed CacheStores post IDs per user for fast retrieval

🔁 Deep Dive: Fanout Strategies

Fanout is the process of distributing a user’s post to their friends’ or followers’ news feeds.

🔹 Fanout on Write (Push Model)

  • Posts are pushed to friends immediately when created.
  • ✅ Fast retrieval
  • ❌ Poor for users with many followers (hotkey problem)
  • ❌ Wastes resources on inactive users

🔹 Fanout on Read (Pull Model)

  • Feed is built on demand when a user opens their app.
  • ✅ Better for scalability and inactive users
  • ❌ Slower retrieval, complex caching

🔹 Hybrid Fanout

  • Use Push for typical users
  • Use Pull for celebrities (millions of followers)
  • Use consistent hashing to avoid hot keys

🧩 Fanout Service Workflow (Detailed)

  1. Fetch friend IDs from graph DB
  2. Filter friends based on user settings (muted, blocked, privacy rules)
  3. Send message with post ID and friend IDs to a message queue
  4. Fanout workers write <post_id, user_id> mappings to cache
  5. Cache management: Store IDs only (not full objects) with size limits to avoid bloat

📥 News Feed Retrieval (Detailed Flow)

  1. User request hits endpoint /v1/me/feed
  2. Load balancer routes to web server
  3. Web server calls news feed service
  4. News feed service fetches post IDs from news feed cache
  5. Hydration: Fetch full post/user/media data from:
    • Post Cache
    • User Cache
    • CDN (for images/videos)
  6. Response is assembled and returned in JSON

🧠 Cache Architecture (5 Layers)

Caching is critical to performance and scalability. Divide your cache tier:

  1. News Feed Cache: Post IDs for each user
  2. Content Cache: Full post content; hot content cached aggressively
  3. Social Graph Cache: Friendship and follower data
  4. Action Cache: Likes, replies, shares
  5. Counters Cache: Like counts, reply counts, follower counts

🧱 Scaling Considerations

TechniquePurpose
Vertical ScalingUpgrade machine specs
Horizontal ScalingAdd more machines
Read ReplicasOffload read traffic
Master-Slave ReplicationImprove availability and resilience
Database ShardingSplit DB by user ID or region
Stateless Web ServersSimplifies scaling
CDNServe static assets (videos, images) quickly

🧠 Monitor: QPS, latency, and cache hit/miss ratios.


🔍 Real-World Interview Questions

  • How would you design Facebook’s news feed system?
  • What is the best fanout strategy for users with millions of followers?
  • How would you support ranking and personalization?
  • Explain how to scale a system to 100 million DAUs.
  • What are the trade-offs between caching entire posts vs just storing IDs?

📚 Recommended Learning Resources


✅ Key Takeaways

  • Use fanout-on-write for low-latency feeds, but combine it with fanout-on-read for scalability.
  • Design for asynchronous operations using message queues.
  • Apply multi-layered caching to reduce DB load.
  • Support privacy filtering, mute settings, and personalized ranking.
  • Monitor metrics, scale horizontally, and use CDNs for media delivery.

📄 Glossary

TermDefinition
FanoutProcess of delivering new posts to followers’ feeds
Hotkey ProblemSystem overload due to a user with massive followers
CDNContent Delivery Network for fast static asset delivery
Hydrated FeedFully constructed feed with usernames, images, and text
Consistent HashingLoad balancing technique to evenly distribute fanout load

🔎 Conclusion

Mastering system design interviews is about more than memorizing patterns — it’s about understanding trade-offs, adapting solutions to specific contexts, and clearly communicating your reasoning. The news feed system is a prime example of balancing performance, scalability, and user experience.

Approach your interview with a solid structure, detailed knowledge, and the confidence that you’ve built a feed system that can scale to millions. 🚀

By SXStudio

Dr. Shell, Fan of Physics, Computer Science, a Cat Dad and a Soccer Player

One thought on “🎯 Cracking the System Design Interview: A Complete Guide to Building a News Feed System”

Leave a Reply

Your email address will not be published. Required fields are marked *