Twitter System Design: The Core Problem
Posting a tweet is easy. The hard part is the home timeline: when you open the app, you expect the latest posts from everyone you follow, instantly, while hundreds of millions of others do the same.
Twitter's engineers have described a key imbalance: reads vastly outnumber writes. Talk summaries cite around 300,000 timeline reads per second against only a few thousand tweet writes per second. That imbalance drives the whole design.
🎯 Quick Answer (30-Second Read)
- Tweets are stored once, each with a time-sortable Snowflake ID.
- Fan-out on write: when you tweet, your tweet's ID is pushed into the cached timeline of each follower, held in Redis.
- Reading a timeline is then just reading a precomputed list of IDs and filling in tweet details from cache.
- Celebrities are the exception: their tweets are merged in at read time instead of being pushed to millions of timelines.
- Peak record: 143,199 tweets per second in August 2013, during a broadcast of Castle in the Sky in Japan.
Requirements
Post tweets, follow users, view home timeline, view a user's profile timeline, like, retweet, search.
Timeline loads in milliseconds. Survive huge spikes (live events). Highly available. A few seconds' delay before followers see a tweet is acceptable.
High-Level Architecture
(write path)"] LB --> READ["Timeline service
(read path)"] WRITE --> ID["Snowflake ID
generator"] WRITE --> TS[("Tweet store
tweet ID → content")] WRITE --> FO["Fan-out service"] FO --> SG[("Social graph
who follows whom")] FO --> TC[("Timeline cache (Redis)
user → recent tweet IDs")] READ --> TC READ --> TCACHE[("Tweet cache")] TCACHE -.-> TS WRITE --> SEARCH["Search indexer"]
The Write Path: Fan-Out on Write
Each follower's home timeline is a list of recent tweet IDs kept in memory. Summaries of Twitter's "Timelines at Scale" talk describe a large Redis cluster with each timeline replicated across three machines, and a cap of around 800 tweets per home timeline. Older history comes from storage when you scroll far back.
Why it works: writing a tweet does more work (once per follower), but reading a timeline, which happens far more often, becomes almost free.
The Celebrity Problem
A user with 100 million followers would trigger 100 million cache writes per tweet. That's slow and wasteful, especially if they tweet often.
| Account type | Strategy |
|---|---|
| Normal users | Fan-out on write: push the tweet ID to every follower's timeline |
| Celebrities | Fan-out on read: don't push; merge their recent tweets into your timeline when you open the app |
The timeline service combines your precomputed timeline with the latest tweets from the celebrities you follow, sorts by ID (which sorts by time), and returns the result. Today's "For You" feed adds a ranking step on top, mixing in recommended tweets.
Snowflake IDs
Twitter created Snowflake to generate unique IDs across many machines without coordination. A Snowflake ID is a 64-bit number:
timestamp (ms)
machine ID
sequence
Because the timestamp comes first, sorting tweets by ID sorts them by time. That's why merging timelines from different sources is cheap. (Instagram uses a similar idea: see Instagram System Design.)
Handling Spikes
On 3 August 2013, during a TV broadcast of Castle in the Sky in Japan, fans tweeted the film's famous line at the same moment. Twitter recorded 143,199 tweets per second, against an average of about 5,700 at the time. Twitter wrote that the record followed a major re-architecture, moving from a monolithic Ruby on Rails app to separate JVM-based services, so spikes like this didn't take the site down.
Patterns that help:
- Queue fan-out work so a spike in writes delays timeline updates by seconds instead of failing tweets
- Cache aggressively on the read path
- Shed non-essential work (like recommendations) under extreme load
- Load-test for events known in advance (finals, elections, New Year)
Frequently Asked Questions
How does the Twitter timeline work?
When someone tweets, a fan-out service pushes the tweet's ID into the cached home timelines of their followers, stored in memory (Redis). Reading your timeline means fetching that list and filling in tweet details from cache. Tweets from accounts with huge followings are merged in at read time instead.
What is a Snowflake ID?
Snowflake is Twitter's system for generating unique 64-bit IDs across many servers. Each ID combines a millisecond timestamp, a machine identifier and a sequence number, so IDs are unique without central coordination and sort by creation time.
What is the most tweets per second ever?
Twitter reported a record of 143,199 tweets per second on 3 August 2013, during a television broadcast of the film Castle in the Sky in Japan. At the time, the average was about 5,700 tweets per second.
Conclusion
Twitter's timeline design optimises for its read-heavy workload: store each tweet once, push tweet IDs into followers' cached timelines on write, handle celebrities by pulling at read time, and use time-sortable Snowflake IDs so merging is cheap. Queues and caching then let the system absorb spikes like the 143,199 tweets-per-second record.
Sources
- Twitter Blog: New Tweets per second record, and how! (2013)
- High Scalability: The architecture Twitter uses to deal with 150M active users
- Twitter Blog: Announcing Snowflake (2010)
Last verified: 2 November 2026.
Related reads: How Twitter's Architecture Handles 500 Million Tweets · Instagram System Design · Redis Explained · Message Queue Explained
I write about system design and how real products are built. Follow on LinkedIn or X, or invite me to speak.