Skip to content

03. Twitter/X Home Timeline — Interview Q&A

~15 min read · Part 4 of 4 (Overview → HLD → LLD → Q&A)

Q1. A tweet gets retweeted a million times in 20 minutes. Why is that harder than a million likes, and how do you handle it? A like touches one counter; a retweet is a fan-out event — it re-injects the tweet into the retweeter's whole follower set. A million retweets averaging 500 followers is ~415k timeline insertions/second from one tweet. Handle it by flagging the original tweet as a hot object once its engagement velocity crosses a low threshold; from then on, retweets of it don't fan out at all — it's served to timelines via a read-time hot-object merge instead. Common wrong answer to avoid: "Just fan out each retweet." That's the storm — hundreds of thousands of writes per second from a single tweet.

Q2. How do you store a retweet? As a small reference row pointing at the original tweet id, not a copy of the tweet body. And flatten chains: retweeting a retweet stores a pointer to the original, so hydration is always one lookup and the retweet count is a single counter on the original. Common wrong answer to avoid: "Copy the tweet into the retweeter's data." That duplicates the body a million times and turns retweet-of-retweet into an unbounded chain.

Q3. Push or pull for the timeline? Hybrid, same as any large feed: push tweet ids into follower timelines for normal accounts (fast reads), pull for celebrities and viral tweets at read time (bounded writes). Twitter's extra rule is applying the hot-object flag to individual tweets, not just accounts, because any tweet can go viral via retweets. Common wrong answer to avoid: "Pure fan-out on write." It collapses under both celebrity authors and viral retweet cascades.

Q4. There's a window between a tweet going viral and being flagged hot. What happens in it? A short burst of fan-out occurs before the velocity counter crosses the threshold. That's acceptable: the sliding-window detector flips within seconds, over-flagging is cheap (it just moves the tweet to the pull path), and readers who arrive after the flag are served via the hot-object merge. The design goal is to make the detection window small, not zero. Common wrong answer to avoid: "Detection is instant, so there's no window." There's always a window; the engineering is bounding it and making over-flagging safe.

Q5. How do live updates work without clients polling? Maintain WebSocket connections in a connection layer; when a followed account tweets, a pub/sub router pushes the new-tweet event to the node holding each online follower's socket. Offline users catch up via a normal timeline read. Polling 180k reads/second would be vastly more wasteful than holding persistent connections. Common wrong answer to avoid: "Clients poll every few seconds." At 300M users that's a massive, mostly-wasted read load, and it's still not real time.

Q6. Why Snowflake-style tweet ids? Time-sortable ids make the timeline a merge of already-sorted lists (push list + hot objects) instead of a global sort by timestamp. They also encode a shard/worker component so ids are unique across a distributed writer fleet without central coordination. Common wrong answer to avoid: "Auto-increment primary keys." A single global sequence is a write bottleneck and doesn't distribute across shards.

Q7. What if fan-out workers fall behind during a big event? The read-time pull of recent tweets from followed accounts is the backstop, so a lagging push path yields slightly-stale timelines rather than missing tweets. Fan-out is an optimization for read speed, not a correctness dependency. Common wrong answer to avoid: "Scale up fan-out workers until it keeps up." You still need the pull backstop; you can't provision for every viral spike, and the hot-object rule is what actually caps the load.

Q8. A user retweets a tweet, then the original is deleted. What does a follower see? Hydration of the dangling reference returns a tombstone ("this tweet is unavailable"). References aren't eagerly cleaned because scanning for every retweet of a deleted tweet is expensive; lazy tombstoning at read time is cheaper and correct. Common wrong answer to avoid: "Cascade-delete all retweets synchronously." That's a fan-out storm in reverse for a popular tweet.

Q9. How does the connection layer scale to millions of sockets? Shard connections across many gateway nodes; a pub/sub backbone (e.g. Redis pub/sub or a message bus) routes each new-tweet event to the specific node(s) holding the relevant followers' sockets. Connection state is soft — on node loss, clients reconnect and re-sync via a durable timeline read. Common wrong answer to avoid: "One server holds all connections." Millions of persistent connections exceed one node; and a single point of failure drops all live updates.

Deeper follow-ups

  • How would you add ML ranking ("For You") on top of the reverse-chronological timeline?
  • How would you build trending topics / search without coupling it to the timeline?
  • How would you handle quote-tweets, which embed one tweet inside another?
  • How would you prevent a coordinated retweet-bot campaign from triggering false hot-object flags?
  • How would you geo-distribute timelines and connections for global users?
  • How would you show accurate retweet/like counts that never decrease under eventual consistency?

How this round is scored

The Twitter round rewards spotting that it is not just Instagram's fan-out problem. The senior signal is recognizing the retweet as a secondary fan-out event and modeling it as a flattened reference, then extending the hot-object rule from accounts to individual tweets so a viral cascade is dampened rather than brute-forced. Putting numbers on the amplification (830 retweets/s × 500 followers = 415k inserts/s) shows you understand why the storm is dangerous. The live-delivery layer and the "push is an optimization, pull is the backstop" framing round out a strong answer; weaker answers stop at "fan out on write" and never confront the cascade.