Design Twitter's tweet feed and timeline system.

What PMs are evaluated on in the Twitter/X system design interview. Trade-offs, the celebrity problem, and the For You vs. Following tension.

"Design Twitter's feed system" (system design PM interview)

This question is not an architecture quiz. Interviewers asking PMs to design Twitter’s feed system are testing whether you can reason about infrastructure trade-offs in product terms: what choices create latency problems, which ones affect creator economics, and how do you know the feed is working? A PM who recites Redis, Kafka, and Cassandra without connecting those choices to user experience fails the same way an engineer fails by missing the celebrity problem entirely.

Scope before designing

State your assumptions out loud, because the numbers reveal the organizing constraint: 500M DAU, 100M tweets per day (roughly 1,150 writes per second), 100B timeline reads per day (roughly 1.15M reads per second). That 1,000:1 read-to-write ratio justifies every caching and fanout decision. If you don’t name it, the interviewer will ask why you chose your approach and the answer won’t hold.

Then name the user job. Consuming a real-time stream from people you follow is a different design than discovering relevant content from strangers. For this interview, assume the core job is: a user opens Twitter and sees a fresh, ranked timeline in under 200ms (p99). That’s the UX bar. Everything else serves it.

The central trade-off: write cost vs. read latency

Fanout-on-write: when a user tweets, the system pushes that tweet ID to every follower’s precomputed timeline cache. Read is fast (O(1) Redis lookup). But write cost scales with follower count. A user with 50M followers tweeting 10 times a day generates 500M write operations. That saturates the fanout queue and creates multi-hour timeline lag, which users experience as broken product, not slow infrastructure.

Fanout-on-read: no precomputation. At read time, fetch recent tweets from everyone you follow and merge them. Read latency spikes badly at scale; the 1,000:1 read ratio makes this unworkable as the default path.

The production answer is the hybrid model: push fanout for regular accounts, pull at read time for high-follower accounts, merge in the application layer before serving. The PM’s job is to name the threshold (accounts with more than roughly 10,000 to 100,000 followers bypass push fanout) as a decision that needs instrumentation to find. You’d measure fanout queue depth and timeline staleness by follower-count bucket, then find where the SLA breaks. Engineering owns the exact number; you own knowing it needs to be found.

Structure a strong answer

strong

"Before designing: are we building a social stream (people you follow) or a discovery feed? I'll assume the core job is a follower-based timeline under 200ms at p99. The organizing constraint is the 1,000:1 read-to-write ratio: 100B reads vs. 100M writes daily. That tells us reads must be precomputed and cached. The core trade-off is fanout-on-write (fast reads, expensive writes) vs. fanout-on-read (cheap writes, slow reads). Neither works alone at scale, so the hybrid model handles it: push tweet IDs to follower caches for regular accounts, pull celebrity tweets at read time, merge in the application layer. The celebrity problem is a product decision: a 50M-follower account tweeting 10x/day generates 500M write operations. If the fanout queue backs up, followers see stale timelines for hours and experience that as broken product. Engineering owns the exact threshold; I'd instrument fanout queue depth and timeline staleness by follower-count bucket to find where latency degrades, then set the threshold there. On ranking: chronological is high-trust, low-engagement. Algorithmic is high-engagement but erodes trust when users can't see why content is surfaced. Twitter's 'For You' vs. 'Following' toggle in 2022 to 2023 is a real product decision with real backlash, and the right answer is legible user control, not picking one. In 2026, AI-ranked feeds are baseline. The PM question is personalization transparency, filter bubbles, and creator reach equity. What I'd measure: timeline load time by percentile, feed freshness (age of the newest tweet in the first screen), creator reach equity across account sizes, and notification-to-open rate as a proxy for feed relevance."

weak

"We'd need a load balancer, a tweet service, Kafka for async processing, Redis for caching, and Cassandra for storage." This is an architecture diagram read aloud. It fails on four counts: it doesn't explain why any choice was made; it doesn't connect decisions to user experience; it ignores the celebrity problem entirely; and it treats the feed as a simple read path rather than a ranked product with real strategic tensions. The follow-up question, "what happens when a user with 50 million followers tweets?" will have no answer.

What the interviewer is probing

Trade-off narration, not component listing: can you explain why fanout-on-write creates a celebrity problem, and why the hybrid model solves it at a product-level cost?
User impact framing: timeline staleness is a retention signal. Multi-hour feed lag reads as broken product.
Honest scope ownership: saying “engineering owns the exact staleness threshold, but I’d instrument fanout queue depth and staleness by follower tier to find it” is a stronger signal than pretending to know the number.
2026 awareness: if you treat algorithmic ranking as a forward-looking option rather than a baseline, your answer reads as 2020. The current PM question is personalization transparency and creator economics.

Numbers worth knowing

Timeline cache stores roughly 800 to 1,000 tweet IDs per user (around 10KB), with a cache hit rate above 99% for active users. Feed ranking inputs include recency, predicted engagement, author relationship strength, user interest model, and media type. The 200ms p99 target is the UX bar PMs defend, not just an engineering target. Snowflake-style time-sortable IDs enable chronological ordering across distributed systems without a global clock.

The viable question for a feed is whether it drives the behaviors that generate revenue and retention. The lovable question is whether users trust it. Twitter/X’s own backlash against “For You” prominence shows what happens when a PM gets the ranking strategy wrong even with a technically correct implementation.

See feasibility is free for the viable/lovable frame that applies across all feed design decisions, and design a news feed for the 2026 ranking layer.