A look at how Twitter timeline works. Twitter’s timeline is the architecture every feed product gets compared to, because Twitter’s engineering team published the most honest write-ups of the trade-offs. The headline pattern is hybrid fanout: write-time fanout for normal users, read-time fanout for celebrities, merged on every read. The cutover threshold is the most-tuned number in the system.
How Twitter Timeline Works: The problem at scale
Twitter’s challenge is the same as Instagram’s, except worse on two axes: the follow graph is denser (a power user follows 1000+ accounts; a celebrity has 100M+ followers), and the per-tweet write rate is enormous (~6,000 tweets/sec globally, peaking during events to 100k+). Each tweet must reach every follower’s timeline in well under a second, even if the tweeter has 100 million followers. Pure fanout-on-write dies on the celebrity case (writing one tweet 100M times to Redis takes minutes). Pure fanout-on-read dies on the power-user case (1000-way join per page load). Twitter’s solution uses both.
The core architecture
When a tweet is posted, the Fanout service makes a routing decision based on the author’s follower count. For most accounts (under ~50k followers), the tweet is appended to every follower’s Redis Timeline, a sorted set per user ID. For celebrity accounts, fanout is skipped and the tweet stays only in the canonical Tweet Store (Manhattan, Twitter’s key-value store). When a user reads their timeline, the system reads their Redis sorted set (their normal-user follows), then separately fetches recent tweets from any celebrities they follow, merges the two, runs them through Ranking ML, and returns. The Redis cache is the fast path; the celebrity merge is bounded to a small number of accounts per user.
Why Twitter’s hybrid matters
The fanout decision isn’t just about throughput. It’s about bounded latency. A celebrity tweeting to 100M followers via pure fanout-on-write would saturate Redis for minutes. A pure fanout-on-read system would mean every user’s timeline read does a 1000-way join. The hybrid caps both: write amplification is bounded (celebrities write once, normal users fan out to their bounded follower sets), and read fan-in is bounded (each user follows at most a few hundred celebrities, typically far fewer).
The crossover threshold (Twitter publicly cited “tens of thousands of followers”) is empirically tuned. It’s the point where the cost of fanout exceeds the read savings, given the actual ratio of reads-to-writes per user. Every feed-heavy system that came after Twitter (Instagram, Bluesky, Threads) converged on essentially the same hybrid because the math is the same.
Ranking on read, not on write
Like Instagram, Twitter’s Redis cache holds tweet IDs in posting-time order, and ranking happens at read time. The Ranking ML re-orders based on predicted engagement, recency, author affinity, and tweet type. This decouples the model from the cache: Twitter can ship a new ranking model multiple times per week without rebuilding any cache state. The cache is a candidate generator; the ranker is the decider.
The one non-obvious insight
Twitter’s biggest scaling problem was never throughput. It was the celebrity spike. A normal tweet is fine. A Beyoncé tweet creates a 100M-write fanout that, even at microsecond-per-write Redis ops, takes 100+ seconds and saturates a Redis shard. The hybrid cutover exists specifically to handle this one case. The lesson: architectures don’t fail at the average case, they fail at the long tail. Twitter’s “fanout-on-read for celebs” is the long-tail workaround that kept the whole system from melting every time a Kardashian tweeted.
Twitter’s timeline is the reference architecture for hybrid fanout. The cutover threshold (~50k followers) is the most-tuned number in the system, and the entire pattern exists to handle one specific long-tail case: the celebrity tweet spike that would otherwise saturate the write path.
Continue learning: