Design Twitter: System Design Interview Guide
Twitter, now X, serves 500 million tweets per day to 600+ million users, with home timelines that must update in under 5 seconds.
Designing Twitter is the canonical timeline generation problem. You decide between push-based fan-out (precompute every follower's timeline) and pull-based aggregation (build on read), and the answer is almost always a hybrid that depends on follower count. It also touches search, ranking, and trending topics.
Asked at: Commonly asked at Meta, Google, Amazon, X (formerly Twitter), LinkedIn, Pinterest, Reddit, and TikTok. It is one of the top 3 system design interview questions for any social product.
Why this question is asked
Design Twitter forces you to confront one of the cleanest trade-offs in system design: fan-out on write vs fan-out on read. It also tests how you handle hot keys (celebrities with millions of followers), real-time ranking, and search at scale.
Requirements
Always clarify these in the first 5 minutes of the interview. Do not start drawing boxes until both lists are agreed.
Functional requirements
- Users post tweets up to 280 characters, with optional media
- Users follow other users
- Users see a home timeline of tweets from followed accounts
- Users can like, retweet, reply, and quote tweet
- Users can search tweets by keyword, hashtag, and user
- Trending topics surface in real time per region
- Notifications fire for mentions, likes, retweets, follows
Non-functional requirements
- Timeline read latency under 200 ms at the 99th percentile
- Tweet visible to followers within 5 seconds
- 99.99% availability for read paths
- Eventual consistency is acceptable for timelines and like counts
- Scale to 500M tweets per day
- Search must surface tweets within seconds of posting
Back-of-envelope scale estimates
Show your math. Pulling numbers from thin air signals you have not thought about the load.
Daily active users
250M
Roughly 40% of 600M registered users active daily based on public reporting.
Tweets per day
500M
Average 2 tweets per DAU. Peak rate during major events (sports finals, elections) is ~10x.
Tweets per second (peak)
50K
500M per day with a 10x peak factor.
Average followers per user
200
Median is much lower (~30), but power users with millions of followers skew the average. Used for fan-out cost.
Timeline reads per second
300K
Reads dominate writes by ~6x. Every app open and every pull-to-refresh is a read.
High-level architecture
When a user posts a tweet, the Tweet Service writes to a sharded SQL store partitioned by user_id and emits an event to Kafka. A Fan-Out Service consumes the event. For normal users (few followers), it precomputes by writing the tweet_id into each follower's timeline cache (Redis sorted set, key user_id, score timestamp). For celebrities (millions of followers), it skips fan-out entirely. When a user requests their home timeline, the Timeline Service reads the precomputed Redis cache for normal-follow content and separately fetches the latest tweets from any celebrities they follow, then merges and ranks before returning. Search runs through a parallel Search Service backed by Elasticsearch, which consumes the same Kafka stream and indexes tweets. Trending topics are computed by a Flink job over the tweet stream.
In a real interview, sketch this on the whiteboard before diving into any single box.
Core components
Walk through each service. The interviewer wants to hear what each one owns, not just the names.
Tweet Service
Owns tweet writes. Persists to sharded SQL (Manhattan in the original Twitter stack, or PostgreSQL shards). Emits a TweetCreated event to Kafka. Reads by tweet_id come from a cache fronting the SQL store.
Follow Graph Service
Stores the follower and following relationships. Heavy-read service. Backed by FlockDB historically, or a custom graph store on top of sharded MySQL. Aggressively cached.
Fan-Out Service
Consumes TweetCreated events. For each follower (up to a threshold like 100K), writes the tweet_id into the follower's timeline cache. For high-follower accounts (celebrities), skips fan-out and relies on the Timeline Service to pull at read time.
Timeline Cache
Per-user Redis sorted set keyed by user_id with tweet_id sorted by timestamp. Capped at the most recent 800 tweets per user. Hit rate is over 99% for active users.
Timeline Service
Reads the user's timeline cache, layers in pulled tweets from celebrity follows, ranks (chronological by default, or by relevance), and returns to the client.
Search Service
Elasticsearch or a custom search engine (Twitter's Earlybird is a custom Lucene fork). Indexes tweets within seconds of creation. Serves keyword, hashtag, and user search.
Trending Service
Flink or Storm job over the tweet stream, grouping by hashtag and region. Surfaces top-N trending per locale every minute.
Data model
Pick the right store per table. Justify each choice with the access pattern, not by reflex.
tweetstweet_id (PK, snowflake ID)author_idtextmedia_urls[]reply_to_tweet_idcreated_atSharded by author_id. Snowflake IDs encode timestamp so they sort naturally. Read by tweet_id is heavily cached.
followsfollower_id (PK partition)followee_id (PK sort)created_atTwo-table denormalization: followers and following lookups are different queries. Often kept in a graph DB or two sharded SQL tables.
user_timelinesuser_id (PK)tweet_ids[] (capped at 800)Redis sorted set. Not durable; rebuilt from the database if a node fails.
tweet_engagementtweet_id (PK)like_countretweet_countreply_countupdated_atCounters maintained by a stream processor. Eventually consistent. Truth lives in the like and retweet event log.
Deep dives
These are the conversations the interviewer is steering you toward. Practice each one until you can talk through it without notes.
Push vs pull for timeline generation
Push (fan-out on write) writes a tweet into every follower's timeline cache when the tweet is created. Reads are O(1): just read the cache. But for a celebrity with 100M followers, every tweet causes 100M cache writes, which is unworkable. Pull (fan-out on read) does the opposite: writes are cheap, but every timeline read has to scatter-gather across all followed users. The hybrid (what Twitter actually does) sets a threshold: users with under 10K to 100K followers get push fan-out; users over the threshold are pulled at read time. Most users get the precomputed timeline. The small number of celebrity follows are merged in at read time. This gives 99% of the speed of pure push without the celebrity blowup.
Handling the celebrity problem (hot keys)
A tweet from Elon or Cristiano can drive millions of timeline reads in seconds. The Timeline Service must read the celebrity's tweets from a tier that scales reads independently of writes. The standard answer is a read-through cache (Redis or Memcached) for celebrity tweets, separate from the per-user timeline cache. The celebrity's recent tweets are pre-warmed into this cache. Timeline reads check the per-user cache plus the celebrity cache and merge. This isolates the hot key from the rest of the system.
Real-time search with Elasticsearch or Earlybird
Tweets must be searchable within seconds of posting. The standard pattern is a Kafka stream consumed by an Elasticsearch indexer. Twitter built Earlybird, a custom Lucene fork optimized for the tweet workload: inverted indexes are built in memory, then flushed to disk in tiered segments. Search queries hit memory first, then on-disk tiers. Tweet ranking inside the search results uses a combination of recency, engagement, and a learned ranking model.
Trending topics in real time
A Flink job consumes the tweet stream, extracts hashtags and entities, and aggregates counts per geographic region (using IP geolocation) per minute. To surface trending, the job compares each topic's current rate against its baseline (last 24 hours rolling average). Topics with the highest velocity (current rate / baseline) are surfaced. This avoids surfacing perpetually popular topics (like #love) and catches genuinely emerging spikes.
Trade-offs to discuss
Every senior interviewer expects you to surface at least 3 of these. Pick the decisions, state the alternatives, and justify your choice.
Push vs pull vs hybrid for timelines
Pure push fails for celebrities. Pure pull is too slow for normal users. Hybrid (push for low-follower, pull for high-follower) gets you 99% of the speed without the celebrity blowup. The threshold is configurable based on infra cost.
Redis vs Memcached for timeline cache
Redis sorted sets give you ordered ranges natively, which fits the timeline read pattern. Memcached is simpler but you'd have to serialize the list and read the whole thing. Redis wins for this workload.
Snowflake IDs vs UUIDs for tweet_id
Snowflake IDs embed a timestamp so they sort by creation order without an extra index. UUIDs are random and require a separate created_at column. Snowflake saves space and speeds range scans for timeline rebuilds.
Eventually consistent like counts vs strict
Strict consistency on like counts requires a transactional write per like, which kills throughput at 500M tweets per day. Eventually consistent counters (maintained by a stream processor) are good enough. The truth lives in the like event log.
Chronological vs ranked timeline
Pure chronological is simple and predictable but mixes important and trivial tweets. Ranked (relevance-based) lifts engagement but is opaque. Twitter offers both: For You is ranked, Following is chronological. The ranking model runs as a separate online service.
How Twitter actually does it
Twitter (now X) historically used Manhattan, a custom multi-tenant KV store, for tweet and user data. The fan-out service was originally Rockdove, a Scala service that wrote into Redis. The search engine is Earlybird, a custom Lucene fork. The follow graph was stored in FlockDB. The recommendation timeline (For You) uses a system called Heron for stream processing and a deep learning ranking model. Many of these systems have been rewritten or replaced under X.
Lessons to study before this interview
If any of these topics are fuzzy, the interviewer will catch it. Each lesson is 15 to 60 minutes with diagrams, code, and a quiz.