Twitter: timelines at scale (fan-out in Redis)

01 · CONTEXT

A timeline is read far more than it is written

Twitter's original timeline shows each person the recent tweets from the people they follow. A public description of the company's architecture, published by High Scalability, records the asymmetry that shapes the design: about 300 thousand requests per second were spent reading timelines and only about 6 thousand per second were writes.

When reads dominate like this, it pays to move work from the read to the write: spend more when publishing a tweet so that opening the timeline is cheap. This case follows that trade-off, shows where it breaks (accounts with many followers), and how the real design came to combine both sides. The focus here is what Twitter did with Redis, not the generic feed problem.

02 · STARTING POINT

Assembling the timeline at read time

The most direct approach is to store nothing precomputed. When someone opens the timeline, the service queries the follower graph, fetches the recent tweets from each followed account, and sorts everything. There is no extra work when publishing, but each read turns into many queries.

1. The user opens the timeline. The load balancer picks a service instance, which has nothing precomputed and has to assemble the result now.

2. The service asks the follower graph which accounts this user follows. The more accounts, the more queries follow.

3. For each followed account, the service fetches the recent tweets from the tweet database. One timeline read unfolds into many reads, and the database absorbs that load every time the app is opened.

4. The service merges the results, sorts them by time, and responds. Response time grows with the number of followed accounts, and this cost repeats on every read.

03 · FAN-OUT ON WRITE

Delivering the tweet to the timelines at write time

The architecture description says that incoming tweets are placed in a large Redis cluster, and that the adopted solution was a fan-out-on-write approach. Instead of computing the timeline when someone reads it, the system inserts each new tweet into the followers' timelines at the moment it is published.

1. The author sends the tweet. The load balancer forwards the request to the tweet service, which validates and writes it.

2. The tweet is written first to the tweet database, which holds the full content and does not depend on any timeline.

3. Instead of delivering to all followers within the publisher's request, the service enqueues the delivery work. The person publishing does not wait for the queue to finish.

4. The delivery process queries the follower graph and inserts the tweet identifier into each follower's timeline, stored in the in-memory cache. The cost grows with the number of followers of the publisher.

5. When a follower opens the timeline, the read service fetches the ready-made list from the cache and fills in the tweets by identifier. Reads no longer walk the follower graph.

The same source describes that a person's main timeline lives in a Redis cluster and has at most 800 entries. The limit keeps the list small and fitting in memory: the cache holds only the recent stretch, and anything older comes from the main storage.

04 · BIG ACCOUNTS

Where fan-out on write breaks and the hybrid design

The cost of fan-out on write is proportional to the number of followers. For a huge account, a single tweet turns into a flood of inserts, and the delivery queues fall behind demand: the source states that the fan-out queues for high-value accounts are backed up all the time. The same source says Twitter was shifting from doing all the work on write to doing more work on read for those accounts, and gives the example of not fanning out a heavily followed account and merging its tweets at read time.

1. With pure fan-out, a huge account's tweet generates a giant task. The delivery queue fills up and that account's tweets take a long time to appear, while the tweets of small accounts waiting behind it are delayed too.

2. In the hybrid design, the delivery process keeps spreading the tweets of regular accounts but does not spread those of heavily followed accounts. The work per tweet stays bounded.

3. The tweets of these accounts live in a cache of their own, read by many users. Since there are few of them and they are read a lot, this cache has a high hit rate.

4. When the timeline is opened, the read service takes the ready-made list from the timeline cache and merges in the tweets of the big accounts the person follows, fetched from the dedicated cache, sorting the result.

5. The price is a bit more work on read, which used to be just a lookup. In exchange, writes from big accounts stop being a bottleneck for the rest of the system.

A systems-interview source describes the same principle in general terms: the hybrid approach lets you choose between fan-out on read and fan-out on write for each account. The decision stops being system-wide and becomes per account.

05 · LESSONS

What to take into the interview

Three ideas come out of the case. First, the read-to-write ratio decides where to pay the cost: if reads dominate, precomputing pays off. Second, the cost of a write grows with the number of followers, so the average hides the tail of giant accounts. Third, the solution is rarely a pure model: the real design mixes both and chooses per account.