Twitter (X) Timeline Architecture: Fanout-on-Write vs Fanout-on-Read

Designing a social media timeline feed like Twitter/X or Instagram presents an asymmetrical read-to-write challenge: users publish tweets once, but timelines are loaded trillions of times per day. Balancing database load requires navigating the architectural trade-offs between Fanout-on-Write and Fanout-on-Read.

1. The Two Competing Paradigms

Approach 1: Fanout-on-Read (The Pull Model)

When a user posts a tweet, it is simply saved to a central tweets table. No precomputation occurs.

• When a user loads their Home Timeline:
• Fetch all user IDs the requester follows.
• Query the tweets table: SELECT * FROM tweets WHERE user_id IN (...) ORDER BY created_at DESC LIMIT 20;
• Merge and return results.
• Pros: Posting a tweet is extremely fast ($O(1)$ write).
• Cons: Reading timelines is disastrously expensive. Merging thousands of followed accounts requires heavy disk I/O and CPU sorting across large distributed database shards.

Approach 2: Fanout-on-Write (The Push Model)

Every user possesses a dedicated in-memory timeline queue (e.g., a Redis List storing the 800 most recent tweet IDs).

• When User A publishes a tweet:
• Fetch all followers of User A.
• Background worker jobs push the new tweet_id onto the Redis timeline queue of every single follower.
• When a follower opens Twitter:
• Query their Redis timeline list: LRANGE timeline:user_id 0 20.
• Return the pre-sorted list in under 5 milliseconds.
• Pros: Sub-millisecond reads with zero dynamic SQL merging.
• Cons: The "Celebrity Problem".

[User Tweets] ──► [Tweet Ingest Service]
                          │
                          ▼
              [Fanout Message Queue]
                          │
              ┌───────────┴───────────┐
              ▼                       ▼
      [Follower A Timeline]   [Follower B Timeline]
         (Redis Cluster)         (Redis Cluster)

2. The Celebrity Problem (The Hotspot Flaw)

Consider an account like Elon Musk or Cristiano Ronaldo with 150,000,000 followers:

• If Twitter uses pure Fanout-on-Write, a single tweet triggers 150 million independent Redis write operations.
• Even at 100,000 writes/sec across worker clusters, fanout would take over 25 minutes! During that window, server CPUs spike, message queues choke, and regular users suffer degraded delivery.

3. The Production Solution: Hybrid Fanout Architecture

To achieve both fast reads and bounded writes, Twitter implemented a Hybrid Adaptive Fanout Architecture:

1. Standard Users (< 25,000 Followers): Use Fanout-on-Write (Push).
2. When an ordinary user tweets, their tweet ID is proactively pushed to their followers' in-memory Redis lists.
3. Celebrity / High-Follower Accounts (> 25,000 Followers): Use Fanout-on-Read (Pull).
4. Celebrity tweets are *never* fanned out to millions of Redis lists.
5. Instead, they are appended solely to the celebrity's individual timeline queue.
6. Dynamic Merge at Read Time:
7. When a user loads their Home Timeline, the system fetches their precomputed in-memory list (holding tweets from regular users they follow).
8. Simultaneously, the system queries the celebrity accounts they follow, fetches their recent tweets, and merges the two lists in RAM using an efficient $K$-way merge algorithm before returning the feed.

4. Key Architectural Trade-offs