1Context and scope
The home timeline is read tens of times for every tweet written, so the classic design precomputes it: a tweet is pushed into each follower’s timeline when it is posted, and loading the timeline is one read plus a ranking pass. Search is a separate path on an inverted index. This design covers home loads, tweets and searches at browser scale, based on Twitter’s engineering write-ups about the timeline, Manhattan and Earlybird.
2Goals and non-goals
Goals
- 6,000 requests a second: 80% home timeline loads, 10% tweets, 10% searches.
- Success at least 99%, p99 at most 500 ms, Apdex at least 0.90.
- Tweets reach timelines and the search index through Kafka with nothing lost.
Non-goals
- Celebrity fan-out on read (the hybrid for accounts with millions of followers).
- Trends, ads and direct messages.
- Media storage and the CDN.
3Capacity estimate
| Quantity | Value | How |
|---|---|---|
| Home loads | ≈ 4,800/s | 80% of 6,000 |
| Timeline cache | 64 GB, 30M timelines, 10 min TTL, 1M ops/s | active accounts are a small share, so most loads hit |
| Ranker | 1,024 slots, 96 vCPU, 4 ms CPU | 4,800 × 4 ms ≈ 19 vCPU busy |
| Tweets | ≈ 600/s | one MySQL write, one Kafka event each |
| Fan-out | 256 workers | each tweet becomes a timeline write per follower plus one index write |
| Searches | ≈ 600/s | 512 slots, 4 ms CPU: 2.4 vCPU busy on 48 |
The rest of the doc
The design · Key concepts · Alternatives considered · Failure modes and fixes · Try it in the lab · Check yourself · Further reading
Unlock the Twitter / X timeline design doc
Every component and why it is there, the capacity numbers behind it, what breaks when you push it and how to fix it, and the same system open in the lab to break and fix yourself. Paid once, on your account.