Design Twitter's News Feed — System Design Interview Walkthrough

"Design Twitter" — or more precisely, its home timeline — is a rite-of-passage system design question. It looks simple ("show posts from people you follow, newest first") but hides one of the most instructive trade-offs in all of system design: fan-out on write versus fan-out on read. This walkthrough runs the whole problem the way you'd run it live.

Step 1 — Clarify requirements

Functional

Users can post (a "tweet").
Users can follow other users.
A user's home timeline shows recent posts from everyone they follow, roughly reverse-chronological.
Out of scope (say so): search, trends, DMs, notifications — unless asked.

Non-functional

Read-heavy and read-latency-critical. Opening the app must feel instant; timeline reads dwarf writes.
High availability over strict consistency — it's fine if a brand-new post takes a few seconds to appear.
Massive scale with a highly skewed follower graph (most users have few followers; a handful have tens of millions).

Naming that skewed graph early sets up the whole design, because the celebrities are what make this hard.

Step 2 — Back-of-the-envelope

Say 300 million daily active users, each opening the timeline a few times a day → on the order of hundreds of thousands of timeline reads per second. Posts are far fewer — maybe tens of thousands per second at peak. That ratio (reads ≫ writes) is the single most important number: it pushes us to do work at write time so reads are cheap.

Step 3 — High-level design

The major pieces:

Post service — accepts new posts, stores them.
Follow/graph service — who follows whom.
Timeline service — assembles a user's home feed.
Data stores — posts, the social graph, and precomputed timelines.
Cache — timelines and hot posts live in memory.

The interesting question is how the timeline service produces a feed. That's the deep-dive.

Step 4 — The core trade-off: fan-out on write vs. read

Fan-out on read (pull): when a user opens the app, fetch the recent posts of everyone they follow and merge them on the fly. Simple and storage-cheap. But a merge across hundreds or thousands of followees on every timeline load is expensive and slow — and reads are our hot path. This scales poorly for active users.

Fan-out on write (push): when a user posts, immediately write that post's ID into the precomputed timeline of every follower (often a per-user list in a cache like Redis). Reads then become trivial: just read your ready-made list. This makes the common case — opening the app — extremely fast. The cost is write amplification: one post by someone with 10,000 followers means 10,000 timeline writes.

For most users, fan-out on write wins because reads dominate and follower counts are modest. But then there's the celebrity.

Step 5 — The celebrity problem (and the hybrid answer)

Fan-out on write breaks for a user with 50 million followers: a single post would trigger 50 million timeline writes — a massive, bursty spike, and much of it wasted on inactive users. This is the classic "hot key" / thundering-herd problem.

The standard answer is a hybrid:

For normal accounts, fan out on write — push their posts into followers' timelines.
For celebrity accounts, don't fan out. Instead, at read time, merge the celebrity's recent posts into the user's precomputed timeline on the fly.

So a user's home feed = (their precomputed, pushed timeline) merged with (recent posts pulled from the few celebrities they follow). This keeps the common case cheap while avoiding the write explosion for high-follower accounts. Explaining why the hybrid exists — the asymmetry between read and write costs, and the skewed follower graph — is exactly the reasoning interviewers reward.

Step 6 — Storage and caching

Posts live in a store keyed by post ID (a distributed key-value or wide-column store). The post body is stored once; timelines store only post IDs (cheap) and hydrate the bodies on read.
Precomputed timelines are per-user lists of recent post IDs, capped in length (you don't need a user's timeline back to the beginning of time) and kept in a fast store like Redis.
Hot posts (a viral tweet) get cached aggressively so millions of hydrations hit memory, not the database.

Capping timeline length is a nice detail: nobody scrolls back 10,000 items, so store, say, the most recent few hundred and fall back to a slower path for deep scrolls.

Step 7 — Follow-ups interviewers love

"How do you handle pagination?" Use cursor/keyset pagination (a post ID or timestamp cursor), not offset — offsets break as new posts arrive.
"What happens when a user with many followers posts — isn't that a huge spike?" That's the celebrity case → hybrid; also, process fan-out asynchronously via a queue so the poster's request returns immediately.
"How do you keep the timeline from being stale?" Merge in very recent posts (including the user's own and celebrities') at read time.
"What about deleted or edited posts?" Timelines store IDs; on hydration, a deleted post is simply skipped, so you don't have to scrub every follower's list.
"Ranking instead of pure reverse-chron?" Acknowledge it: a ranked feed adds a scoring step at read time over a candidate set — a reasonable extension, but confirm scope first.

Common mistakes

Picking one fan-out strategy and defending it to the death. The insight is the trade-off; the strong answer is the hybrid.
Ignoring the celebrity case. If your design does 50 million synchronous writes on a single post, you've missed the crux.
Storing full post bodies in every timeline. Store IDs; hydrate on read.
Using offset pagination. It double-serves and skips items on a live feed.

Practice this out loud

The follow-ups on this problem come fast — "okay, now what about the celebrity?" is where interviewers separate candidates. On Whitepad, the Twitter-style feed is a preset problem: a senior AI interviewer runs it by voice, watches your whiteboard, and pushes on exactly the fan-out and hot-key trade-offs above, then scores you like a real interviewer would. Design it once here, and the hybrid answer will be second nature in the room.