Practice/Bloomberg/Design a Social Media Feed Generation System

Design a Social Media Feed Generation System

System DesignMust

Problem Statement

Design a social media feed system that generates and populates personalized feeds for users on platforms like Twitter, Instagram, or Facebook. When a user opens the app, they should see a ranked, paginated timeline composed of posts from accounts they follow, mixed with trending or recommended content. New posts should appear in followers' feeds within seconds of publication, and the feed must feel fresh and responsive even during peak traffic.

The system must handle the full spectrum of social graph sizes: regular users with hundreds of followers, micro-influencers with tens of thousands, and celebrities with millions. Each user's feed reflects their unique follow graph, content preferences, and engagement history. The fundamental trade-off is between write amplification (pushing posts to followers' feeds at publish time) and read complexity (assembling feeds on demand at read time). Bloomberg's emphasis on real-time data delivery and high-throughput pipelines makes this a natural interview topic, testing your ability to design scalable fanout strategies, caching layers, and ranking pipelines.

Key Requirements

Functional

• Personalized home feed -- generate a ranked, paginated feed of posts from followed accounts that loads within 300 milliseconds and stays fresh as new content arrives
• Follow and unfollow -- users can follow and unfollow accounts, with feed content reflecting relationship changes within minutes
• Post publishing with low-latency propagation -- when a user publishes a post (text, images, video), it appears in followers' feeds within 5 seconds for active users
• Content ranking and filtering -- apply relevance-based ordering (not purely chronological) and enforce visibility rules (blocked users, private accounts, content moderation flags)

Non-Functional

• Scalability -- support 500 million monthly active users, 100,000 posts published per second during peak hours, and a median of 200 follows per user
• Reliability -- 99.9 percent availability for feed reads; tolerate individual component failures without visible degradation
• Latency -- p95 feed load time under 300ms; p99 under 500ms for the initial page of results
• Consistency -- eventual consistency is acceptable; a post may take a few seconds to appear in all followers' feeds, but should never be permanently missing

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Fanout Strategy: Write vs Read vs Hybrid

The most important architectural decision is how posts reach followers' feeds. Interviewers want to see you reason through the trade-offs rather than picking one approach blindly.

Hints to consider:

• Fanout-on-write (push model) pre-materializes each user's feed in a cache at publish time, delivering fast reads but creating massive write amplification for users with millions of followers
• Fanout-on-read (pull model) assembles the feed at request time by querying each followed account's post timeline, avoiding write amplification but increasing read latency and complexity
• A hybrid approach pushes posts to followers' feeds for regular users (under 50,000 followers) and merges celebrity posts at read time, balancing write cost and read performance
• Consider batching fanout operations and using priority queues so celebrity posts (which affect millions of feeds) do not block delivery of regular posts

2. Feed Ranking and Personalization

Users expect feeds ranked by relevance, not just chronological order. Interviewers assess whether you can integrate a ranking pipeline into the feed assembly process without destroying latency.

Hints to consider:

• Apply a lightweight ranking model during feed assembly that scores posts based on engagement signals (likes, comments, shares), recency, content type preference, and relationship strength
• Pre-compute feature vectors for posts at publish time (engagement counts, media type, author popularity) and store them alongside feed entries so ranking at read time requires no additional lookups
• Use a two-phase approach: a candidate generation phase that retrieves the most recent N posts from the materialized feed, followed by a ranking phase that reorders them based on the scoring model
• Cache ranked feeds with short TTLs (30 to 60 seconds) so identical requests from the same user do not trigger repeated ranking computations

3. Caching and Pagination

Feed reads dominate the workload and must be extremely fast. Interviewers look for multi-layer caching strategies and correct pagination semantics that handle the constantly changing nature of feeds.

Hints to consider:

• Store the most recent feed entries (e.g., top 200 posts per user) in Redis sorted sets keyed by user ID, with post timestamps as scores for efficient range queries
• Use cursor-based pagination (not offset-based) to ensure consistent page-through even as new posts arrive; the cursor encodes the timestamp and post ID of the last seen item
• Implement a cache-aside pattern where a cache miss triggers feed reconstruction from the source of truth (post timelines in Cassandra), which is then cached for subsequent requests
• Separate the "head" of the feed (latest 20 posts, served from Redis) from the "tail" (older posts, served from Cassandra) to optimize for the common case

4. Handling Celebrity Accounts and Hot Partitions

A single post from a celebrity with 50 million followers can generate billions of cache writes. Interviewers probe whether you recognize this as a show-stopping scalability issue and have concrete mitigation strategies.

Hints to consider:

• Maintain a "celebrity" flag for accounts exceeding a follower threshold; their posts are never fanned out on write and are instead merged at read time using a separate celebrity timeline cache
• Rate-limit fanout workers to prevent a single celebrity post from monopolizing the write pipeline and delaying delivery of regular posts
• Shard fanout queues by follower ID ranges so multiple workers can process different segments of a celebrity's follower list in parallel
• Pre-warm the celebrity timeline cache so read-time merging adds minimal latency (fetch from cache, not from the database)

Suggested Approach

Step 1: Clarify Requirements

Confirm scope and constraints. Ask about user scale (total users, daily active users, concurrent online users) and the median and maximum follower counts. Clarify whether the feed is purely chronological or ranked by relevance. Determine what content types are supported (text, images, video, links) and whether media is inline or linked. Ask about privacy rules: do private accounts require explicit follow approval, and how do blocked users affect feed visibility? Confirm acceptable staleness for feed freshness and whether real-time push notifications for new posts are in scope.