Design Twitter

Problem Statement

Design Twitter as a fan-out system where freshness, delivery order, and hot users create the real scaling pressure. For Design Twitter, name the critical user action, the data that must remain correct, and the first bottleneck that appears when traffic grows.

Deep-Dive: Clarifying Questions for Twitter

1. What is the tweet volume? Twitter processes approximately 500 million tweets per day (about 6,000 tweets/second average, spiking to 20,000+ during major events).
2. How should the home timeline be generated? This is the core design question. Fan-out on write (pre-compute timelines) vs. fan-out on read (compute on demand)? The celebrity problem (users with 50M+ followers) makes this critical.
3. Do we need real-time delivery? Should tweets appear in followers' timelines within seconds or is a delay of 30-60 seconds acceptable?
4. What media types do we support? Text only (140-280 chars), images (up to 4 per tweet), videos (up to 2:20), GIFs, polls? Media significantly changes storage and bandwidth requirements.
5. Do we need search? Real-time search of all tweets is a massive infrastructure challenge requiring an inverted index updated in real-time.
6. What about the follow graph? The average user follows 400 accounts, but some follow 5,000+. The follow graph is the foundation of timeline generation.

Specific Functional Requirements

1. Post Tweet: Users can post text tweets (280 chars), optionally with images (up to 4), videos, or polls
2. Home Timeline: Display a feed of tweets from accounts the user follows, ordered by relevance/recency
3. Follow/Unfollow: Users can follow other users, with follow counts displayed on profiles
4. Like, Retweet, Reply: Standard engagement actions with real-time count updates
5. Search: Real-time search across all public tweets with relevance ranking
6. Notifications: Real-time notifications for mentions, likes, retweets, and new followers
7. Trending Topics: Identify and display currently trending hashtags and topics

Specific API Endpoints

POST /api/v1/tweets
  Body: { "text": "Hello world!", "media_ids": ["abc123"], "reply_to": null }
  Response: { "id": "1234567890", "text": "...", "created_at": "...", "user": {...} }

GET /api/v1/timeline/home?cursor=abc&limit=20
  Response: { "tweets": [...], "next_cursor": "def" }

POST /api/v1/users/:user_id/follow
  Response: { "following": true, "follower_count": 1234 }

GET /api/v1/search?q=system+design&type=recent&cursor=abc
  Response: { "tweets": [...], "next_cursor": "def" }

GET /api/v1/trends?location=US
  Response: { "trends": [{ "name": "#SystemDesign", "tweet_count": 50000 }] }

Specific Data Model

Users: id (BIGINT), username (VARCHAR), display_name, bio, follower_count, following_count, created_at

Tweets: id (BIGINT, Snowflake ID), user_id, text (VARCHAR 280), media_urls (JSON), reply_to_id, retweet_of_id, like_count, retweet_count, created_at

Follows: follower_id (BIGINT), followee_id (BIGINT), created_at — Sharded by followee_id for efficient "get all followers" queries

Timeline Cache (Redis): Key = user_id, Value = sorted set of tweet_ids with timestamp scores. Each user's timeline cache holds the most recent 800 tweet IDs. This is the pre-computed timeline for fan-out-on-write.

The Celebrity Problem: For users with more than 10,000 followers, do NOT fan out on write. Instead, merge their tweets into the timeline at read time. This hybrid approach (fan-out-on-write for normal users, fan-out-on-read for celebrities) is what Twitter actually uses.

Specific Back-of-the-Envelope Numbers

Traffic:

• 300M daily active users (DAU), 500M tweets/day
• Average user checks timeline 10 times/day = 3B timeline reads/day = ~35,000 reads/second
• Tweet writes: 500M/day = ~6,000 writes/second
• Average user has 400 followers: each tweet fans out to 400 timeline caches

Fan-out calculation:

• 500M tweets * 400 avg followers = 200 billion timeline cache updates/day
• Celebrity optimization: exclude users with 10K+ followers from fan-out, reducing this by ~30%

Storage:

• Tweet text: 280 bytes avg * 500M/day * 365 = ~50 TB/year for text alone
• Media: 1MB avg image * 100M images/day * 365 = ~36 PB/year for media
• Timeline cache (Redis): 300M users * 800 tweet IDs * 8 bytes = ~1.9 TB of Redis

Latency targets:

• Timeline load: under 200ms (pre-computed timeline from Redis)
• Tweet posting: under 500ms (write tweet, start async fan-out)
• Search: under 300ms (inverted index lookup)

Original DosiBridge notes for Design Twitter

This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Design Twitter is to connect the concept to a fan-out system where freshness, delivery order, and hot users create the real scaling pressure. That framing changes the design discussion from definitions to operating choices.

What makes this topic distinct

• Core Entity: For Design Twitter, decide the core entity before choosing tools; otherwise the design looks clean but fails when twitter changes.
• Read/Write Path: For Design Twitter, decide the read/write path before choosing tools; otherwise the design looks clean but fails when twitter changes.
• Contention Point: For Design Twitter, decide the contention point before choosing tools; otherwise the design looks clean but fails when twitter changes.
• Abuse Path: For Design Twitter, decide the abuse path before choosing tools; otherwise the design looks clean but fails when twitter changes.
• Recovery Workflow: For Design Twitter, decide the recovery workflow before choosing tools; otherwise the design looks clean but fails when twitter changes.

Distinct angle: Twitter is graph fanout under celebrity skew

Twitter-like design is defined by the follow graph and celebrity skew. A normal user's tweet can be pushed to follower timelines, but a celebrity tweet may need read-time merging to avoid millions of writes. The original design value is the hybrid fanout rule: precompute where cheap, merge where fanout would overload the system, and measure timeline freshness separately from tweet creation latency.

Design Twitter correctness boundary

For this problem, separate the user-visible action from background work. The correctness boundary is the smallest state transition that must not be duplicated, lost, or reordered. Naming that boundary makes the solution more original than a stock API/database/cache template.

Design Twitter scaling bottleneck

The first bottleneck should be described in the language of this system: a hot timeline, a contested seat, a busy wallet ledger, a media-processing queue, or a search index update delay. That bottleneck decides which component deserves the deepest interview discussion.

Production review question

If Design Twitter suddenly receives 10x traffic, which entity becomes contested first, and what queue, lock, shard, or cache protects that entity without hiding correctness bugs?

Practical metric to track

Track twitter health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Design Twitter, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.

Sources

• Design Twitter — Reference
• Source: System-Design-Overview