Design Twitter / X

Design Twitter / X — the 45-minute interview walkthrough

This lesson is the interview version of designing a social feed: how to structure the discussion and which deep dives to prepare. The full reference design is the case study Design Twitter / X in this chapter. The class-level design (User, Tweet, Timeline objects) is in Design Twitter/X in the LLD course.

The heart of this problem is one question: when someone opens the app, how do you assemble, in milliseconds, the latest posts from everyone they follow, for hundreds of millions of users, where a few accounts have tens of millions of followers?

Minutes 0–5: clarify requirements

• Core features: post a tweet, follow users, read the home timeline (posts from people you follow), read a user timeline (one person's posts). Likes, retweets, replies and search can be mentioned as scope you'll touch briefly.
• Scale assumptions: ~300M daily active users, ~500M tweets/day (~6,000/s average, far more at peaks), and reads dominate: each user refreshes their timeline many times a day, so timeline reads run to hundreds of thousands per second.
• Latency: the home timeline in well under ~200 ms.
• Consistency: a new tweet may take a few seconds to appear in followers' timelines. Eventual consistency is fine for feeds. Saying so early simplifies everything.
• Ordering: reverse-chronological, or ranked? Start chronological, and mention ranking as an extension.

Minutes 5–15: the high-level design

 client ─▶ API gateway ─┬─▶ Tweet service ─────▶ Tweet store (by tweet ID) + media on blob storage/CDN
                        │         │
                        │         └─ "tweet created" event ─▶ Fan-out workers ─▶ Timeline cache (per user: list of tweet IDs)
                        │                                             ▲
                        ├─▶ Social graph service (followers / following)
                        │
                        └─▶ Timeline service: read cached IDs → merge celebrity tweets → hydrate tweet bodies → return page

• Tweet service stores tweets, keyed by a time-sortable ID (Snowflake style: timestamp + machine + sequence), so sorting by ID is sorting by time.
• Social graph service knows who follows whom.
• Timeline cache: for each user, a capped list (for example the latest 800) of tweet IDs in a fast in-memory store.
• Timeline service answers reads from that cache, then hydrates IDs into full tweets (text, author, counts) via a tweet cache.

Minutes 15–35: the deep dives

1. Fan-out: push, pull, or both

Fan-out on write (push): when Asha tweets, workers look up her followers and append the tweet ID to each follower's cached timeline.

• ✅ Reads are trivial and fast: the timeline is precomputed.
• ❌ A tweet from an account with 50 million followers means 50 million cache writes, which takes minutes and wastes work on inactive users.

Fan-out on read (pull): store nothing per user. At read time, fetch recent tweets from everyone the user follows and merge them.

• ✅ Posting is cheap.
• ❌ Reading is expensive for users who follow thousands of accounts, and reads are the hot path.

Hybrid (the standard answer):

• Push for normal accounts (the vast majority).
• Don't push tweets from celebrities (accounts above a follower threshold). At read time, fetch the recent tweets of the few celebrities the user follows and merge them into the precomputed timeline.
• Optionally skip fan-out to inactive users, and build their timeline on demand when they return.

This hybrid is the key insight interviewers look for. Explain why the threshold exists: it's where push's write amplification becomes more expensive than pull's read-time merge.

2. Storage choices

• Tweets: a horizontally scalable store sharded by tweet ID (or by user ID if user-timeline reads dominate), plus a large cache for hot tweets. Tweets are immutable, apart from counters and deletes, which makes caching easy.
• Timelines: in-memory lists or sorted sets per user, holding only IDs, not tweet bodies, to keep memory small. The cache is rebuildable: if a user's timeline is lost, regenerate it by pulling from their followees.
• Social graph: two indexes, followers(user) and following(user), sharded by user ID. Celebrity follower lists are enormous and must be paginated.
• Counters (likes, retweets): sharded counters or approximate counters updated asynchronously, since exact real-time counts aren't needed.

3. Hydration and pagination

The timeline cache returns IDs. The service then batch-fetches tweet bodies and author profiles (multi-get from caches) and filters deleted or blocked content. Pagination uses a cursor (the last tweet ID seen), not an offset, so new tweets arriving at the top don't shift pages and cause duplicates.

4. Posting path and reliability

The tweet is written durably first, then a "tweet created" event goes onto a queue for fan-out. The author sees their own tweet immediately (read-your-writes, via their user timeline). Followers see it seconds later as fan-out completes. Fan-out workers must be idempotent, since appending the same ID twice should be harmless, because queue deliveries can repeat.

Minutes 35–45: trade-offs and wrap-up

• Push vs pull is a trade-off between write amplification and read latency. The hybrid gets most of the benefit of each.
• Memory: caching IDs only, capped per user, keeps the timeline cache feasible. Inactive users don't get precomputed timelines.
• Consistency: eventual consistency for feeds, stronger guarantees for the write itself.
• With more time: ranked timelines (candidate generation from the cached timeline plus a ranking model), search (an inverted index fed by the tweet stream), trends (stream processing over hashtags), notifications, and multi-region replication.

Common mistakes in interviews

• Only describing a SQL query joining tweets and follows, and stopping there.
• Pure fan-out-on-write without addressing celebrity accounts.
• Storing full tweet bodies in every follower's timeline instead of IDs.
• Offset-based pagination on a constantly changing feed.

Follow-up questions this topic invites — and their answers

Q: What threshold makes an account a "celebrity"? A: It's tuned empirically. It's the follower count where the cost of pushing to every follower (write volume and fan-out delay) exceeds the cost of merging that account's recent tweets at read time for its followers. Thresholds in the tens to hundreds of thousands of followers are typical, and some systems also consider how often the account posts.

Q: How do you handle a user following many celebrities? A: Cap how many celebrity sources are merged per read, cache each celebrity's recent tweet list (it's shared by all their followers, so it's very cacheable), and merge using the time-sortable IDs, a k-way merge of already-sorted lists.

Q: How are deleted tweets removed from millions of timelines? A: Usually not by rewriting every timeline. Mark the tweet deleted in the tweet store, and filter it out during hydration. Stale IDs in timelines are simply skipped, and caches age them out.

Q: How would you add a ranked ("For you") timeline? A: Generate candidates (the cached chronological timeline, celebrity tweets, plus recommendations from outside the follow graph), compute features (engagement, author affinity, recency), score them with a ranking model, then apply diversity and safety rules. The chronological fan-out system becomes the candidate source.

Q: Why use Snowflake-style IDs instead of auto-increment? A: They can be generated independently on many machines without coordination, they sort roughly by time (so ordering and cursor pagination work on the ID itself), and they don't expose exact tweet counts the way sequential IDs do.