Twitter's Timeline Architecture

Company Context

Twitter (now X) serves over 500 million tweets per day to hundreds of millions of active users. The home timeline — the reverse-chronological (and later algorithmic) feed of tweets from accounts a user follows — is the core product experience. Rendering a timeline must happen in under 200 milliseconds, even for users who follow thousands of accounts.

The timeline problem is deceptively hard. A naive approach — "query all tweets from accounts this user follows, sort by time, return the top 200" — requires a massive fan-in operation that would crush the database under real-world traffic patterns.

The Problem at Scale

Consider the numbers: an average user follows 200 accounts. Rendering their timeline means fetching recent tweets from 200 accounts and merging them by timestamp. At 200 million daily active users, that is 40 billion tweet-lookup operations per day just for timeline rendering. Users refresh multiple times per day, multiplying the load further.

On top of this, Twitter has extreme write-to-read asymmetry for popular accounts. A celebrity with 50 million followers posting one tweet generates 50 million timeline entries. Whether this work happens at write time or read time fundamentally shapes the architecture.

Architecture Solution

Twitter uses a hybrid fanout architecture that combines two approaches:

Fanout on Write (Pre-computation)

When a regular user posts a tweet, Twitter's fanout service pushes the tweet ID into the pre-computed timeline of every follower. Each user's timeline is stored in a Redis cluster as a sorted set of tweet IDs, ordered by time.

The flow:

1. User posts a tweet. The tweet is written to the tweets datastore.
2. The fanout service looks up the user's follower list.
3. For each follower, the service inserts the tweet ID into that follower's timeline in Redis.
4. When a follower opens the app, their timeline is a simple Redis read — no computation needed.

This approach trades write amplification for read speed. A user with 1,000 followers causes 1,000 Redis writes. But each timeline read is a single Redis fetch returning pre-sorted tweet IDs, which is sub-millisecond.

Fanout on Read (On-Demand) for High-Follower Accounts

For accounts with millions of followers (celebrities, news outlets, politicians), fanout on write is prohibitively expensive. One tweet from an account with 50 million followers would generate 50 million Redis writes, taking minutes and consuming massive resources.

Twitter handles these accounts differently: their tweets are not fanned out at write time. Instead, when a user's timeline is requested, the system:

1. Reads the pre-computed timeline from Redis (tweets from regular accounts)
2. Queries the tweets datastore for recent tweets from high-follower accounts the user follows
3. Merges the two result sets on the fly

This hybrid approach caps the maximum fanout at write time while keeping the read-time merge small (typically only a handful of high-follower accounts in any user's follow list).

Key Technical Decisions

Redis for timeline storage. Each user's timeline is a Redis sorted set with tweet IDs as members and timestamps as scores. Redis's sorted set operations (ZADD, ZRANGEBYSCORE) are O(log N) and sub-millisecond. Twitter maintains multiple Redis clusters with replication for fault tolerance. The dataset is memory-bound — storing 800 tweet IDs per timeline for 300 million users requires significant Redis capacity.

The threshold for fanout-on-read. Twitter set a follower count threshold (reportedly around 10,000-100,000) above which accounts switch from fanout-on-write to fanout-on-read. The exact threshold was tuned based on the cost of fanout versus the latency of on-demand merge.

Tweet hydration. The timeline stores only tweet IDs, not full tweet objects. When the client requests a timeline, the IDs are fetched from Redis, then the full tweet objects (text, media, engagement counts) are fetched from the tweet storage service and assembled into the response. This separation keeps the timeline cache compact and allows tweet data to be updated (edit tweet, engagement count changes) without modifying timelines.

Engagement ranking. The original reverse-chronological timeline was replaced with an algorithmic timeline that ranks tweets by predicted engagement. The ranking model runs after the candidate tweets are retrieved (from both fanout-on-write and fanout-on-read), scoring each tweet and reordering them before returning the response.

Strengths

• Sub-200ms timeline rendering for most users
• Write amplification is bounded by excluding high-follower accounts from fanout
• Simple read path for the common case (single Redis fetch)
• Clean separation between timeline assembly and tweet hydration

Weaknesses

• Massive Redis infrastructure cost for storing pre-computed timelines
• Fanout on write introduces latency for tweets to appear in followers' timelines (typically 3-5 seconds)
• High-follower accounts experience inconsistent delivery timing compared to regular accounts
• Deleting a tweet requires removing it from millions of pre-computed timelines
• The hybrid approach adds system complexity and multiple code paths

Lessons for System Design

The Twitter timeline is the classic example of the push-vs-pull tradeoff in system design. Pure push (fanout on write) is fast to read but expensive to write. Pure pull (fanout on read) is cheap to write but slow to read. The hybrid approach gets the best of both worlds at the cost of complexity.

This pattern appears in many systems: notification delivery (pre-compute for most, batch for high-traffic sources), news feed generation (Facebook uses a similar hybrid), and email delivery (mailing lists with millions of subscribers use segmented fanout).

Interview Relevance

The Twitter timeline is one of the most frequently asked system design questions. Interviewers expect you to identify the fanout problem, propose the pre-computation approach, recognize the high-follower edge case, and arrive at the hybrid solution. Being able to discuss the Redis data model, the threshold decision, and the tradeoff between write amplification and read latency demonstrates depth.

Original DosiBridge notes for Twitter's Timeline Architecture

This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Twitter's Timeline Architecture is to connect the concept to a fan-out system where freshness, delivery order, and hot users create the real scaling pressure. That framing changes the design discussion from definitions to operating choices.

What makes this topic distinct

• Practice Loop: For Twitter's Timeline Architecture, decide the practice loop before choosing tools; otherwise the design looks clean but fails when twitter changes.
• Implementation Exercise: For Twitter's Timeline Architecture, decide the implementation exercise before choosing tools; otherwise the design looks clean but fails when timeline changes.
• Review Checkpoint: For Twitter's Timeline Architecture, decide the review checkpoint before choosing tools; otherwise the design looks clean but fails when twitter changes.
• Failure Drill: For Twitter's Timeline Architecture, decide the failure drill before choosing tools; otherwise the design looks clean but fails when timeline changes.
• Comparison Target: For Twitter's Timeline Architecture, decide the comparison target before choosing tools; otherwise the design looks clean but fails when twitter changes.

Production review question

If a team adopts Twitter's Timeline Architecture, what observable signal proves it helped instead of only making the architecture diagram more fashionable?

Practical metric to track

Track twitter-timeline health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Twitter's Timeline Architecture, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.