1What is the 'Lady Gaga problem' in news feed design?
Vetora📰Interview Toolkit
Interview Walkthrough: News Feed / Timeline
A comprehensive interview walkthrough for designing a social media news feed or timeline. Covers the push vs pull fanout trade-off, the celebrity problem, feed ranking, pagination, and media handling.
Overview
Designing a social media news feed is one of the most architecturally rich system design interview questions. The core problem is deceptively simple: when a user opens their app, show them a chronologically or relevance-sorted feed of posts from people they follow. But at the scale of platforms like Twitter (500 million tweets per day), Instagram (2 billion daily active users), or Facebook (billions of posts per day), the naive approach of querying all followed users' posts on every feed load collapses under the weight of fan-in queries.
The central tension in news feed design is push versus pull. In a push model (fanout-on-write), when a user creates a post, the system immediately writes that post's ID to the timeline of every follower. Each user's timeline is pre-computed and stored, typically as a sorted set in Redis, so reading a feed is a simple cache lookup -- fast and cheap. The cost is borne at write time: when a user with 1,000 followers posts, the system performs 1,000 write operations to update follower timelines. This is manageable for most users, but breaks down catastrophically for celebrities. When a user with 100 million followers posts, the system must perform 100 million writes, which can take minutes and creates enormous write amplification. This is called the Lady Gaga problem or the celebrity problem.
In a pull model (fanout-on-read), the system does nothing at write time -- posts are simply stored in the poster's outbox. When a user opens their feed, the system queries the posts table for all users they follow, merges and sorts the results, and returns the top N posts. This is cheap at write time but expensive at read time. If a user follows 500 people, the system must issue 500 queries (or a large IN clause) and merge-sort the results. With millions of concurrent feed loads, the database becomes the bottleneck. The pull model works when read frequency is low relative to write frequency, but social media feeds are read far more often than they are written to.
The production solution is a hybrid approach. Normal users (those with fewer than a threshold number of followers, typically 10,000-100,000) use the push model: their posts are fanned out to follower timelines at write time. Celebrities and high-follower accounts use the pull model: their posts are not fanned out but are instead fetched and merged into the timeline at read time. When a user loads their feed, the system retrieves the pre-computed timeline from Redis (containing posts from normal followed users) and merges in recent posts from any followed celebrities by querying the celebrities' outboxes. This limits write amplification while keeping read latency low for the vast majority of feed loads.
Beyond the fanout strategy, a production news feed requires several additional components. Feed ranking determines the order of posts -- chronological is simplest, but most modern platforms use ML-based ranking that scores posts by predicted engagement (likes, comments, shares, time spent). Pagination must use cursor-based (keyset) pagination rather than offset-based, because the feed is constantly changing and offset-based pagination leads to duplicate or missing posts. Media handling involves storing images and videos in object storage (S3) and serving them through a CDN, with the feed containing only media URLs rather than the media itself.
Key Points
- 1Push (fanout-on-write) pre-computes timelines at write time, giving O(1) read latency from Redis sorted sets. The cost is write amplification proportional to follower count, which is prohibitive for celebrity accounts.
- 2Pull (fanout-on-read) computes the feed at read time by querying followed users' posts. It has zero write amplification but high read latency, especially for users who follow many accounts.
- 3The hybrid approach pushes for normal users and pulls for celebrities, bounding write amplification while maintaining fast reads. The follower threshold (typically 10K-100K) determines the push/pull boundary.
- 4Cursor-based pagination is essential for feeds because new posts are constantly being added. Offset-based pagination (OFFSET/LIMIT) causes posts to shift between pages, leading to duplicates and missed posts.
- 5Feed ranking uses ML models to predict engagement probability for each post, ordering by a score that combines recency, affinity (how often the user interacts with the poster), content type, and predicted engagement.
- 6Timeline storage in Redis sorted sets (score = timestamp or rank score, member = post_id) enables efficient range queries for pagination and constant-time insertion for fanout writes.
Simple Example
The Newsletter vs Newspaper Analogy
Push-based fanout is like a newsletter: when an author publishes, the article is delivered to every subscriber's mailbox. Reading is instant -- just open your mailbox. But if an author has 100 million subscribers, printing and delivering 100 million copies takes a long time. Pull-based fanout is like a newspaper stand: articles are published in one place, and readers go to the stand to browse when they want to read. Reading is slower (you have to walk to the stand and flip through papers) but publishing is instant. The hybrid approach is like subscribing to newsletters for your favorite small authors (push) but visiting the newsstand for major publications (pull) that everyone reads anyway.
Real-World Examples
Twitter famously evolved through all three approaches. The original pull-based system queried the tweets table on every timeline load, which became unsustainable as the user base grew. They migrated to a push-based system using Redis sorted sets for pre-computed timelines, dramatically improving read latency. When the celebrity problem caused multi-minute fanout delays for high-follower accounts, they adopted the hybrid approach: push for users with fewer than a threshold of followers, pull and merge for celebrities.
Instagram switched from a chronological feed to an ML-ranked feed in 2016, which increased engagement but required a more complex feed generation pipeline. Their system uses a two-stage ranking approach: a lightweight first-pass model scores thousands of candidate posts, then a heavyweight second-pass model re-ranks the top few hundred. The ranking model considers signals like post age, user-poster affinity, content type, and predicted engagement probability.
LinkedIn's feed merges two distinct sources: posts from connections and followed accounts (social feed) and algorithmically recommended content from outside the user's network (discovery feed). The merge ratio is determined by ML models that balance user engagement with content diversity. LinkedIn uses a follow-the-sun architecture where feed generation happens in the data center closest to the user, with cross-region replication of social graph and post data.
Trade-Offs
| Aspect | Description |
|---|---|
| Read Latency vs Write Amplification | Push gives O(1) read latency but O(followers) write cost. Pull gives O(1) write cost but O(followed) read cost. The hybrid approach optimizes for the common case (fast reads for most users) at the cost of additional system complexity. |
| Chronological vs Ranked Feed | Chronological ordering is simple, predictable, and gives users a sense of completeness. ML-ranked feeds increase engagement metrics but frustrate users who want to see everything in order, and they require significant ML infrastructure for model training and serving. |
| Consistency vs Availability | A user who just posted expects to see their post in their own feed immediately (read-your-writes consistency). In a push model, there is a fanout delay before the post appears in followers' feeds. The system must ensure the author sees their own post immediately while accepting eventual consistency for followers. |
| Storage vs Compute | The push model trades storage (pre-materialized timelines in Redis for every user) for compute (no on-the-fly query merging at read time). At scale, Redis storage costs for hundreds of millions of timelines can be substantial, but the alternative is compute-intensive read-time queries that must execute within latency SLOs. |
Case Study
Twitter's Hybrid Fanout Architecture
Scenario
Twitter's pure push-based timeline system created pre-computed timelines in Redis for all 300+ million users. When a user tweeted, a fanout service wrote the tweet ID to every follower's timeline. This worked well for the average user with hundreds of followers, but celebrities with tens of millions of followers caused fanout storms: a single tweet from a top account triggered millions of Redis writes, taking minutes to propagate and creating massive spikes in Redis write load. During major events (Super Bowl, elections), multiple celebrities tweeting simultaneously could overwhelm the fanout infrastructure.
Solution
Twitter implemented a hybrid approach with a configurable follower threshold. Users below the threshold (approximately 10,000 followers) continued to use push-based fanout. Users above the threshold were marked as 'pull' accounts. When a user loaded their timeline, the system retrieved the pre-computed timeline from Redis (containing posts from push accounts) and then queried a separate datastore for recent posts from followed pull accounts. These pull results were merged into the pre-computed timeline on the fly, sorted by timestamp or relevance score. The threshold was tunable per user based on their posting frequency and follower engagement patterns.
Outcome
The hybrid approach eliminated fanout storms from celebrity accounts, reducing peak Redis write load by over 70%. Timeline read latency increased by only 10-15ms on average because the pull-and-merge step was optimized with aggressive caching of celebrity posts. The overall system could handle 3x more tweets per second during peak events without degradation. The architecture also made it easier to layer ML-based ranking on top, because the merge step was already computing a relevance-sorted feed.
Common Mistakes
- ⚠Proposing only push or only pull without discussing the trade-offs of each approach. Interviewers expect you to understand why neither pure strategy works at scale and to arrive at the hybrid solution through reasoned analysis.
- ⚠Using offset-based pagination (page 1, page 2) for the feed. New posts are constantly being added, which shifts the offset and causes users to see duplicate posts or miss posts entirely. Always use cursor-based pagination with a stable cursor (e.g., last seen post ID or timestamp).
- ⚠Ignoring the celebrity problem. If your design uses push-based fanout and you do not address what happens when a user with 50 million followers posts, the interviewer will probe this gap. Proactively mention the follower threshold and the hybrid approach.
- ⚠Storing media content (images, videos) directly in the post record or database. Media should be stored in object storage (S3) with a CDN for delivery. The post record contains only the media URL, keeping the database lightweight and reads fast.
Related Concepts
See Interview Walkthrough: News Feed / Timeline in action
Explore system design templates that use interview walkthrough: news feed / timeline and run traffic simulations to see how these concepts perform under real load.
Browse TemplatesCompare push vs pull fanout strategies in the social feed simulator
Metrics to watch
fanout_latency_mstimeline_read_latency_mscache_hit_rate
Test Your Understanding
2Why is cursor-based pagination preferred over offset-based pagination for social media feeds?
3In the hybrid fanout approach, which users' posts are pre-computed into follower timelines at write time?