Social & content · Advanced

Twitter/X home timeline

Hybrid fan-out: push tweets into cached timelines, pull celebrity tweets at read time.

Every part, and why it is there

Readers & tweeters

Hundreds of millions of people open their home timeline far more often than they tweet, so reads outnumber writes by roughly a hundred to one. The whole design is shaped around making that read cheap.

Media CDN

Photos and videos are fetched by URL from edge caches, so the timeline API only ever returns small JSON. Without it every image view would cross the ocean to the origin.

Media storage

Uploaded images and videos live in blob storage behind the CDN. It is cheap and durable, and the CDN absorbs nearly all of the read traffic.

API gateway

One front door that checks the session, applies rate limits and routes reads to the timeline service and writes to the tweet service.

Home timeline service

Builds a timeline in three steps: read the precomputed list of tweet ids from cache, merge in recent tweets from the few celebrities the user follows, then hydrate ids into full tweets. Keeping this a read of prepared data is what makes it fast.

Timeline cache (Redis)

Holds each active user’s timeline as a capped list of the latest ~800 tweet ids, replicated across machines. Storing ids instead of tweets keeps it small enough to fit in memory; users who have not logged in for weeks are dropped and rebuilt on demand.

Ranking model

Scores the candidate tweets for the “For You” view (likelihood of a like, reply or repost) so the best ones float up. The chronological “Following” view can skip it, which is a useful fallback when ranking is slow.

Tweet store (Manhattan)

Every tweet by id, in a distributed key-value store. Hydration is a big multi-get of ids, which this kind of store answers quickly at any scale.

Social graph service

Answers “who follows X” and “which celebrities does Y follow”. Both the fan-out workers and the timeline reader depend on it, so it is its own service with its own store.

Follow graph

The follower edges, stored so that listing all followers of an account is a fast sequential scan. Twitter originally built FlockDB for exactly this.

Tweet service

Validates and stores a new tweet, then publishes an event. It returns to the author as soon as the tweet is durable; spreading it to followers happens afterwards.

New-tweet events

A durable log of new tweets that several consumers read independently: fan-out, search indexing, notifications. If fan-out falls behind, tweets wait here rather than being lost.

Fan-out workers

For each new tweet, look up the author’s followers and push the tweet id onto every follower’s cached timeline. Authors above a follower threshold are skipped; their tweets are merged in at read time instead.

Asked in interviews at

  • amazon
  • cloudflare
  • google

Learn more

All system design examples