How Twitter Timeline Works: Fan-out on Write vs Read

The Timeline Problem

When a user opens Twitter, they expect to see tweets from everyone they follow, sorted by time (or relevance). With 500 million tweets per day and users following thousands of accounts, this is surprisingly hard.

The Core Challenge

Numbers:

• 400M+ daily active users
• 500M+ tweets per day
• Users follow 100-10,000+ accounts
• Timeline must load in < 1 second

The Question:

When should you compute the timeline?

• When a tweet is posted? (fan-out on write)
• When a user requests their timeline? (fan-out on read)

Fan-Out on Write

How It Works:

1. User posts tweet
2. System finds all followers
3. Write tweet to each follower's timeline cache
4. User opens app → read from cache

Advantages:

• Fast reads (timeline pre-computed)
• Simple read path
• Predictable read latency

Disadvantages:

• Slow writes (especially for celebrities)
• Storage intensive (many copies of each tweet)
• Wasted work for inactive users

Celebrity Problem:

• Lady Gaga has 80M+ followers
• Each tweet = 80M writes
• Takes too long to propagate

Fan-Out on Read

How It Works:

1. User posts tweet → write to tweets table
2. User opens app
3. Query: "Get latest tweets from everyone I follow"
4. Merge and sort results

Advantages:

• Fast writes (one write per tweet)
• Storage efficient
• Fresh data always

Disadvantages:

• Slow reads (many queries to merge)
• High read latency
• Database load spikes

Twitter's Hybrid Approach

The Solution: Hybrid Fan-Out

For Regular Users:

• Fan-out on write
• Tweets written to follower timelines
• Fast reads from cache

For Celebrities:

• No fan-out on write
• Their tweets fetched at read time
• Merged with pre-computed timeline

Detection:

• Threshold: ~10K followers
• Above threshold = celebrity treatment
• Below threshold = normal fan-out

Timeline Architecture

Components:

1. Tweet Service

• Handles tweet creation
• Stores tweets in database
• Triggers fan-out

2. Fan-Out Service

• Determines which followers to write to
• Handles celebrity detection
• Manages write queues

3. Timeline Service

• Maintains timeline caches
• Handles merging for celebrity tweets
• Serves timeline requests

4. Social Graph Service

• Who follows whom
• Efficient follower lookups
• Graph traversal

Timeline Cache

Structure:

• Per-user timeline cache in Redis
• Stores tweet IDs (not full tweets)
• Limited to last N tweets (e.g., 800)

Storage:

• Key: user_id
• Value: sorted set of (tweet_id, timestamp)
• Efficient range queries

Eviction:

• LRU or time-based
• Old tweets fall off
• Celebrity tweets not cached

Tweet Ranking

Chronological vs Algorithmic:

Chronological:

• Sort by timestamp
• Simple, predictable
• May miss important tweets

Algorithmic ("For You"):

• ML-based ranking
• Engagement prediction
• Personalization
• More complex, better engagement

Ranking Signals:

• Recency
• Engagement (likes, retweets)
• User relationship strength
• Content type
• Previous interactions

Real-Time Delivery

Push to Timeline:

• WebSocket connection
• New tweets streamed to client
• Inserted into UI without refresh

Challenges:

• Connection management at scale
• Graceful degradation
• Offline handling

Scaling Considerations

Write Path:

• Fan-out is parallelized
• Queue-based processing
• Background workers

Read Path:

• Heavy caching
• Read replicas
• Geographic distribution

Storage:

• Sharded databases
• Time-series optimization
• Cold storage for old tweets

Data Model

Tweets Table:

• tweet_id (snowflake ID)
• user_id
• content
• created_at
• reply_to, retweet_of (relationships)

Timeline Cache:

• user_id → [(tweet_id, score), ...]
• Score = timestamp or ranking score

Social Graph:

• Adjacency lists
• Follower/following counts
• Graph database or sharded MySQL

Key Optimizations

1. Snowflake IDs

• Time-ordered unique IDs
• Encode timestamp in ID
• No separate timestamp lookup needed

2. Batch Fan-Out

• Group followers by shard
• Batch writes to same shard
• Reduce round trips

3. Lazy Loading

• Don't fan-out to inactive users
• Compute on demand if needed
• Saves storage and compute

Interview Application

When designing a social feed:

Key Questions:

• How many users? Follows?
• Read/write ratio?
• Latency requirements?
• Consistency requirements?

Approach:

1. Estimate scale
2. Choose fan-out strategy
3. Design caching layer
4. Handle edge cases (celebrities)
5. Discuss trade-offs

Trade-offs:

• Write latency vs read latency
• Storage vs computation
• Freshness vs performance

Twitter's timeline is a canonical system design example that demonstrates the complexity of seemingly simple features at scale.