System Design Interview: Design Twitter

"Design Twitter" is the canonical feed-generation problem. It looks simple — post a tweet, read a timeline — but the interesting part is generating each user's home timeline at scale, where the right answer is a hybrid fan-out strategy. The interviewer wants to see you discover that the naive approaches both break, and reason your way to the blend.

Move through it deliberately: clarify requirements, estimate the read/write ratio, design tweet storage, then the timeline — comparing fan-out-on-write vs fan-out-on-read and arriving at the hybrid that handles the celebrity problem. The walk-through below follows that path.

1. Clarify requirements

Scope to the core feed problem. Users post tweets, follow others, and read a home timeline that merges tweets from everyone they follow, newest-first.

• Functional: post a tweet, follow/unfollow, home timeline (people you follow), user timeline (one author), basic search out of scope unless asked.
• Non-functional: very read-heavy, low-latency timeline reads, high availability; eventual consistency for the timeline is acceptable.
• Clarify: media, replies/threads, and ranking — acknowledge, then scope a chronological feed for this round.

2. Estimate scale and the read/write ratio

The ratio drives the whole design. Reads vastly outnumber writes — users scroll their timeline far more often than they post. With hundreds of millions of users, the system must make timeline reads cheap even if that makes writes more expensive. That single observation points toward precomputing timelines.

3. Tweet storage

Tweets themselves are simple, append-heavy data. Store them in a horizontally-partitioned store keyed by tweet ID (with a time-sortable ID like a Snowflake ID so ordering is embedded). A separate social graph store holds follower/following relationships.

• Tweets: distributed store, sharded by tweet ID; time-sortable IDs give cheap chronological ordering.
• Social graph: who-follows-whom, optimized for 'get all followers of X' and 'get all followees of X'.
• A cache (Redis) holds hot data — recent tweets and precomputed timelines.

4. Timeline generation: fan-out on write vs read

This is the heart of the problem. Fan-out-on-write (push) inserts each new tweet into every follower's precomputed timeline list at post time — timeline reads become a cheap cache lookup, but a post by someone with millions of followers triggers millions of writes. Fan-out-on-read (pull) builds the timeline at read time by merging recent tweets from everyone you follow — cheap writes, but expensive, slow reads for users following many accounts.

• Fan-out-on-write: fast reads, expensive writes; great for normal users.
• Fan-out-on-read: cheap writes, expensive reads; needed for accounts with huge follower counts.

5. The celebrity problem and the hybrid

Neither pure approach wins, so combine them. Use fan-out-on-write for the vast majority of users, but for 'celebrity' accounts with very large follower counts, do NOT fan out their tweets on write. Instead, at read time, merge a follower's precomputed timeline with a live pull of the few celebrities they follow. This caps the write amplification while keeping reads fast — the answer interviewers are listening for.

6. Trade-offs to verbalize

Finish on the tensions: write amplification vs read latency (the whole fan-out decision), the storage cost of precomputed timelines vs recomputing them, and consistency — a few seconds of delay before a tweet appears in followers' timelines is acceptable, so eventual consistency lets you scale. Explicitly stating the hybrid's threshold (how you classify a 'celebrity') shows senior judgment.

Practice Twitter system design with real-time help

Natively's system design interview assistant can keep you structured during a live round — suggesting the next dimension to cover and surfacing trade-offs in real time, all on your own device.

• System Design Interview Assistant
• System Design: Netflix
• System Design: WhatsApp
• Software Engineer Interview Questions