Twitter's Timeline Fan-Out
Twitter precomputes each user's timeline at write time but handles very-high-follower accounts at read time, because neither strategy alone survives both ends of the distribution.
The two options, and why each fails alone
Fan-out on read. Store each post once. When a user opens their timeline, query the posts of everyone they follow and merge. Writes are trivial; reads are an expensive scatter-gather across hundreds of accounts, executed far more often than writes occur. Reads outnumber writes by orders of magnitude, so this puts the cost in the wrong place.
Fan-out on write. When a user posts, immediately write it into the precomputed timeline of every follower. Reads become a single sequential fetch — extremely fast. But a post by an account with tens of millions of followers becomes tens of millions of writes, a single event that lands like a denial-of-service on your own infrastructure.
The hybrid
Twitter's published approach uses fan-out on write for ordinary accounts and excludes very-high-follower accounts, merging their posts in at read time.
So most users' timelines are precomputed and instantly available, while the handful of accounts that would generate write storms are handled by a cheap merge on the read path — cheap precisely because there are so few of them per timeline.
Why this is a general pattern
Power-law distributions break uniform strategies. Almost every social, commercial and content system has a small number of enormously popular entities and a very long tail. A design tuned for the median entity fails on the head; a design tuned for the head is wasteful for everything else.
The reusable move is treat the head as a special case, explicitly. The same shape appears in:
- Multi-tenant sharding — the largest tenants get dedicated shards.
- Caching — the hottest keys get request coalescing or a local in-process cache.
- Rate limiting — the largest customers get bespoke limits.
- Inventory — the most contended SKUs get a different concurrency strategy.
The lesson to state explicitly
Look at the distribution before choosing an algorithm. "How does this behave for the 99.9th percentile entity?" is a design-time question, and the answer is frequently that you need two strategies and a threshold — which is less elegant and considerably more correct.