The big idea

What happens when you open Twitter?

You follow hundreds of accounts. The instant you open the app, you want a feed of their latest posts — newest and most relevant first — in well under a second.

Naively, you’d ask the database for the latest tweets from everyone you follow and merge them on the spot. That works for ten followers and collapses for three hundred million users. The whole art of a feed is deciding when to do that merge: at read time, or ahead of time.

How to read this: Each step opens with a real design decision — you make the call before I show you what ships. Watch the diagram grow, and at the end stall the fan-out to see why posting and delivery are decoupled. Hit Begin.

Step 1 · The skeleton

Post a tweet, store a tweet

Strip it down and there are two jobs: write a tweet, and read a feed of them. Both need a home for the tweet itself.

Design decision: Two jobs: post a tweet and read a feed of them. What’s the minimal home for a tweet?

The call: A Tweet Service writes tweet_id → {author, text, ts} to a Tweet Store. — One durable row per tweet is the immutable spine; everything else is about getting that tweet’s id in front of the right people. A posted tweet never changes, so it’s perfectly cacheable and safe to copy into many feeds.

Put a server in the middle and a Tweet Store behind it. To post, the Tweet Service writes a row tweet_id → {author, text, ts}. Everything else we build is about getting that tweet in front of the right people, fast.

Tweets are immutable: A posted tweet never changes — it’s only created, read, or deleted. That makes tweets perfectly cacheable and lets us safely copy a tweet’s id into millions of feeds without worrying it’ll go stale.

Step 2 · The graph

Who follows whom?

A feed is defined entirely by the follow graph: your home timeline is "the tweets of everyone I follow." So we need a fast way to answer two questions — who do I follow? and who follows me?

Design decision: A feed is "tweets of everyone I follow." What do you need from the follow graph, and how do you store it?

The call: A directed graph indexed both ways (forward + reverse lists). — Follows are one-way edges (follower → followee). Both directions are queried constantly — your feed needs your followees, fan-out needs a poster’s followers — so store and index both as adjacency lists.

Add a Graph Service backed by an adjacency store. Following is just an edge follower → followee. The two directions get queried constantly, so we store and index both: a forward list and a reverse list.

It’s a directed graph: Follows are one-way (you can follow someone who doesn’t follow back), so edges have direction. At Twitter scale this is billions of edges — a specialized graph/KV store, not a JOIN on a relational table.

Step 3 · Read-time merge

The naive feed: pull

First instinct: when you open the app, look up everyone you follow, fetch their recent tweets, merge by time, return. This is the pull (fan-out on read) model.

Add a Timeline Service that does exactly this. It’s simple and writes are cheap — posting just stores one row. But each read now fans out to hundreds of accounts and merges thousands of tweets, every single time someone refreshes. Reads outnumber writes ~100:1, so we’ve put the heavy work on the hottest path.

Pull = cheap writes, brutal reads: Fan-out on read keeps posting trivial but makes every feed load expensive and slow. For a read-dominated product, that’s backwards — which sets up the central trick of the next step.

Step 4 · Fan-out on write

Precompute every inbox

Reads are killing us. But notice: a tweet is written once and read by all a person’s followers. What if we did the expensive merge at write time instead?

Design decision: Reads outnumber writes ~100:1, and a tweet is written once but read by all followers. How do you fix the hot read path?

The call: Fan-out on write: at post time, push the tweet id into each follower’s precomputed inbox. — A Kafka event triggers a worker that reads the poster’s followers and writes the tweet id into each follower’s Redis inbox. Reading a feed becomes reading one list — O(1), sub-millisecond. Trade a burst of writes for cheap reads — the right call for a read-dominated product.

When someone posts, drop an event on a stream (Kafka). A Fan-out Worker asks the Graph Service for the poster’s followers and pushes the new tweet id into each follower’s Timeline Cache — a precomputed inbox in Redis. Now reading a feed is just reading one list: O(1), sub-millisecond.

Push the work to write time: We trade a single, cheap read for a burst of writes when you post. Since feeds are read far more than tweets are written, that trade is a huge win — this is fan-out on write.

Step 5 · Scale the stores

Billions of tweets and edges

At hundreds of millions of tweets a day, no single database holds the Tweet Store or the follow graph, and no one Redis box holds every inbox.

Design decision: No single box holds the tweet store, the follow graph, or every inbox. How do you partition them?

The call: Shard by access key: tweets by tweet id, graph + inboxes by user id. — Pick the shard key to match the read: a feed read keyed by user id touches just one timeline shard, and random-ish ids spread load evenly — no hotspots (until a celebrity, next). Add nodes to grow.

Shard everything. Partition the Tweet Store by tweet id, the graph by user id, and the timeline cache by user id — so each user’s inbox lives on a predictable node. Every component scales out horizontally; add machines as you grow.

Shard by the access key: Pick the shard key to match how you read: tweets by tweet id, inboxes by user id. Then a feed read touches just one timeline shard, and load spreads evenly with no hotspots — until a celebrity shows up (next).

Step 6 · Rank it

Newest isn’t best

A pure reverse-chronological inbox buries the good stuff under noise. People engage far more with a feed that surfaces what they actually care about.

Design decision: A reverse-chronological inbox buries the good stuff. How do you surface what people care about — without scoring all of Twitter?

The call: Two stages: retrieve candidates from the inbox, then rank just those. — The precomputed inbox is a cheap candidate set (a few hundred ids); a heavier ranking model scores only those by predicted engagement (affinity, recency, media, behaviour) and reorders them. Retrieve cheap, rank narrow — every modern feed works this way.

Insert a Ranking Service on the read path. It pulls the candidate tweet ids from the inbox, scores each by predicted engagement (author affinity, recency, media, past behaviour), and returns the reordered list. The inbox becomes a candidate set, not the final order.

Retrieve, then rank: Almost every modern feed is two stages: cheaply retrieve a few hundred candidates (the inbox), then run a heavier ranking model on just those. You never score all of Twitter — only what could plausibly appear.

Step 7 · The sharp edges

The celebrity problem

Fan-out on write breaks for a star with 100M followers: one tweet would trigger 100M inbox writes — a "fan-out storm" that lags delivery for everyone.

Design decision: A star with 100M followers posts — fan-out-on-write means 100M inbox writes, a "fan-out storm." How do you avoid it?

The call: Hybrid: push for normal accounts, pull celebrities at read time and merge. — Don’t fan out a celebrity’s tweets; pull their recent posts when a follower loads their feed and merge into the precomputed inbox. Fast feeds for the common case, no storm for the rare one. Knowing when each model wins — and combining them — is the senior-interview answer.

Go hybrid. For normal accounts, push (fan-out on write). For a handful of celebrities, don’t fan out — instead, pull their recent tweets at read time and merge them into your precomputed feed. You get fast feeds for the common case and avoid the storm for the rare one. Layer on rate limits, abuse checks, and graceful handling of deletes.

Hybrid fan-out: The real answer is "both." Push for the many, pull for the few mega-accounts, and merge at read. Knowing when each model wins — and combining them — is exactly what a senior design interview is looking for.

You did it

You just designed Twitter’s feed.

• T — w
• A —
• P — u
• F — a
• S — h
• R — e
• H — y