Design Twitter / X

Design Twitter/X: users post short tweets, follow others, see a home timeline, and search recent tweets.

1. Clarify the requirements

Before drawing anything, ask questions. These are the answers an interviewer would typically give:

How many users?

300M monthly active users, about half active daily. Each posts ~2 tweets a day.

Which features?

Post tweets, follow, home timeline, and keyword search. DMs, ads and trends are out of scope.

Media?

About 10% of tweets have a 1 MB image.

Timeline freshness?

New tweets should show up within ~5 seconds.

Read/write ratio?

Timeline reads outnumber tweet writes by about 100 to 1.

2. Estimate the scale

Assumptions: 300M MAU, 50% daily active, 2 tweets per user per day, 10% of tweets carry a 1 MB image.

• Daily active users: about 150M users300M × 50% = 150M.
• Tweet write QPS: about 3472 tweets/s150M × 2 ÷ 86,400 ≈ 3,500/s (peak ≈ 7,000).
• Media storage per day: about 30 TB300M tweets × 10% × 1 MB = 30 TB/day.

3. The high-level design

1. Users reach stateless API serversA load balancer spreads requests over stateless API servers; reading timelines is far more common than tweeting.
2. Store tweetsTweets go to a store sharded by tweet ID. Snowflake IDs are unique across servers and sort by time, which timelines need.
3. Images and video via a CDNMedia goes to object storage and is served by a CDN.
4. Home timelines in a cacheEach user's home timeline (tweet IDs) is precomputed and kept in memory.
5. Fan-out on write, with a celebrity exceptionWorkers push each tweet's ID into followers' timelines. Accounts with millions of followers are skipped and merged at read time instead.
6. SearchTweets are also streamed into a sharded inverted index for search.
7. Watch it in productionMetrics and alerts close the loop: timeline p99, fan-out lag and search freshness.

4. The components and what each one does

Load balancer Load balancer

Spreads requests over the stateless servers behind it, health-checks them and routes around a dead one. Rate limits abusive clients.

API servers App servers

Stateless: any server can handle any request, so you scale out horizontally. Checks the auth token on every request.

Tweets NoSQL / KV store · Manhattan / Cassandra

Sharded by tweet ID (Snowflake: unique, time-sortable); replicated with failover.

CDN CDN

Serves images and video from the edge.

Timeline cache Cache · Redis

Home timelines: the latest tweet IDs per user.

Fan-out workers Workers

Push tweet IDs into followers' timelines; skip celebrities (hybrid).

Search index Search index · Earlybird / Elasticsearch

Inverted index sharded by term, updated in near real time.

Metrics & alerts Metrics & alerts

Dashboards and alerts on p99 latency, error rate, queue depth and cache hit ratio, so a bottleneck shows up before it becomes an outage.

5. Deep dive: timeline generation & search

How are home timelines built for users who follow celebrities? How is search kept fresh?

• Fan-out on write into timeline caches for normal accounts; pull for celebrities.
• Store only tweet IDs in timeline caches and hydrate on read.
• New tweets are indexed asynchronously into a search index (inverted index).

6. What interviewers listen for

• Tweet, timeline and search APIsDefine the three core endpoints with pagination for timelines.
• Data model: tweets, users, followsEntities and keys drive storage and sharding.
• Push vs pull, hybrid for celebritiesThe defining trade-off of timelines.
• Time-sortable unique tweet IDsSnowflake-style IDs give unique, roughly time-ordered tweet IDs without coordination.
• Database replication and failoverA single database is a single point of failure. Replicas give redundancy and read capacity; failover promotes a replica when the primary dies.
• Partition (shard) data as it growsOne machine eventually can't hold the data or the write load. Say how you'd split it and by which key.

7. Follow-up questions

1. An account with 100M followers tweets. How long until followers see it, and what does it cost your system?
2. How quickly does a new tweet become searchable, and how do you keep search from slowing down tweeting?
3. One database shard holds all of a superstar's tweets and keeps overloading. What do you do?

The design in a nutshell

• LB → stateless API servers; tweet service writes to a sharded tweet store with Snowflake IDs; media to object storage + CDN.
• Fan-out workers (via queue) push tweet IDs into followers' timeline caches, skipping celebrities.
• Timeline read: cached IDs + celebrity tweets merged at read time, hydrated from tweet/user caches.
• Search: tweets streamed into a sharded inverted index.
• Replication, rate limiting on posting, monitoring timeline latency and fan-out lag.

Related lessons: Fanout on write vs fanout on read · Deep dive: news feed retrieval and the cache layers