How Twitter’s Fan‑Out Timeline Architecture Scales Real‑Time Feeds

The problem: delivering a tweet to millions of followers instantly

\n

When a user posts a tweet, every follower expects to see it in their home timeline within seconds. A naïve pull‑based design would require each follower’s client to query the database on every refresh, creating huge read spikes and latency. Twitter needed a write‑heavy solution that could keep reads cheap and low‑latency.

\n

Thesis: pre‑compute timelines with a fan‑out workflow and fall back to read‑time merge for ultra‑popular accounts

\n

The core idea is to push a new tweet to the timeline cache of each follower at write time (fan‑out). For most users this yields O(1) reads because the timeline is already materialized in memory. Accounts with millions of followers would cause prohibitive write amplification, so their tweets are handled differently: they are merged into the timeline at read time.

\n

How the fan‑out works

\n

\n
1. Ingest – A tweet arrives via the write API and is written to the primary tweet store.
\n
2. Fan‑out worker pool – The tweet is broadcast to a set of stateless workers. Each worker looks up the follower list of the author and writes the tweet ID into the Timeline Service cache for each follower.
\n
3. Timeline Service – An in‑memory cache (often a sharded Redis‑like store) holds the pre‑computed timeline for each active user. Reads are simple cache lookups, giving sub‑millisecond latency.
\n

\n

Hybrid path for high‑follower accounts

\n

Accounts whose follower count exceeds a threshold (e.g., >1 M) are treated as \"heavy hitters.\" When such a user posts:

\n

\n
• The tweet is still stored in the primary tweet store.
\n
• Instead of fanning out to millions of cache entries, the system marks the tweet as \"heavy.\"
\n
• At read time, the Timeline Service first returns the cached timeline from regular fans, then merges any heavy‑hitter tweets by querying the tweet store and interleaving them based on timestamp.
\n

\n

This shifts work from the write path (O(N) where N = follower count) to the read path (O(H) where H = number of heavy hitters followed by the user), keeping write load manageable.

\n

Worked example: a user with 10 k followers posts a tweet

\n

Suppose user alice has 10 000 followers and none of them are heavy hitters.

\n

\n
1. Alice’s tweet receives ID T12345 and is written to the tweet store.
\n
2. The fan‑out worker pool receives T12345. For each follower ID in Alice’s list, the worker issues a cache LPUSH timeline: T12345 operation.
\n
3. After the fan‑out completes, each follower’s timeline cache now contains T12345 at the head of their list.
\n
4. When any follower opens their home timeline, the Timeline Service returns the cached list; the tweet appears instantly with no additional database lookup.
\n

\n

If one of Alice’s followers also follows a celebrity with 5 M followers, that celebrity’s tweet will not be in the cache; it will be fetched from the tweet store and merged at read time for that follower.

\n

Trade‑offs and limitations

\n

\n
• Write amplification – A tweet from a user with 1 M followers results in ~1 M cache writes, increasing network and memory pressure.
\n
• Memory pressure – The Timeline Service must retain a timeline for every active user; as active users grow, RAM usage grows linearly.
\n
• Consistency lag – There is a brief window between when a tweet is written to the tweet store and when it finishes propagating through the fan‑out workers, during which some followers may not see the tweet.
\n
• Complexity of hybrid merge – Read‑time merging requires careful timestamp ordering and duplicate removal, adding latency for users who follow many heavy hitters.
\n

\n

Actionable takeaway

\n

If you are designing a real‑time feed system:

\n

\n
1. Start with a write‑side fan‑out to an in‑memory timeline cache for the majority of users.
\n
2. Identify a follower‑count threshold beyond which fan‑out becomes prohibitive and switch those producers to a read‑time merge strategy.
\n
3. Monitor cache hit ratios and memory usage; adjust the threshold and consider sharding or tiered caching as the active user base scales.
\n
4. Accept a small consistency window for the fan‑out path and expose it via metrics (e.g., \"time to appear in 99% of follower timelines\") to guide SLA decisions.
\n

\n

By separating the write and read paths and handling ultra‑popular accounts specially, you can achieve low‑latency reads while keeping write load within feasible limits.