Design Twitter — System Design Interview Guide

Functional requirements

• Post a tweet (text, up to 280 chars; optional media attachment)
• Follow and unfollow another user
• View a personalized home timeline of posts from followed users in roughly reverse-chronological order
• View any user's profile timeline (their own posts only)
• Search posts by keyword (basic — full-text not required for v1)

Non-functional requirements

• Read-heavy: ~100:1 read-to-write ratio (timeline loads >> posts)
• Timeline freshness: new posts visible to followers within ~5 seconds (p99)
• Availability: 99.99% (eventual consistency on timelines is acceptable)
• Scale: 500M DAU, average ~2 posts/user/day = ~1B posts/day, peak QPS ~150K writes, ~15M reads

Capacity estimation

Anchor on the public 2022 Twitter scale: roughly 500M daily active users, ~1B posts/day, average post size ~200 bytes (text + metadata; media stored separately). Storage for posts alone: 1B × 200B = 200 GB/day = ~73 TB/year before replication. With 3× replication and indexes: ~250-300 TB/year. Peak write QPS: 1B / 86,400 sec × 3 (peak factor) ≈ 35K writes/sec; reads at 100:1 push peak to ~3.5M reads/sec. Media (photos/video) dominates byte storage — assume 10% of posts have media at avg 500 KB = 50 TB/day, served from edge caches.

For timeline materialization (fanout-on-write): average follower count is ~200, but the distribution is power-law — top accounts have 100M+ followers. A naïve fanout of a celebrity post would write 100M timeline entries per post; this is the central design challenge.

High-level design

Clients (mobile, web) connect through an API gateway that handles TLS, rate limiting, and auth-token validation. Behind the gateway, stateless application servers route requests to three core services: a post service (write path), a timeline service (read path), and a user-graph service (follow relationships).

The write path is straightforward: a new post is written to a sharded relational store keyed by user_id, then a write-ahead event is published to a message queue. A fanout worker consumes the queue and, for ordinary users, pushes the post into each follower's precomputed home-timeline cache (an in-memory store, sharded by user_id, holding the most recent ~800 timeline entries per user as a sorted list). Reads then become a single in-memory cache lookup — the heart of the read-heavy optimization.

The user-graph service maintains follow edges in a separate sharded store (sharded by follower user_id so 'who do I follow' is a single-shard read). A search service tails the post stream into an inverted-index cluster for keyword queries. Media (photos, video) is uploaded directly to object storage and served via a CDN — application servers never touch media bytes. Hot user profiles and recent posts are cached in an in-memory tier in front of the relational store using consistent hashing for cache-key distribution.

Deep dive — the hard problem

The deep dive is the celebrity-fanout problem. Pure fanout-on-write doesn't work when one user has 100M followers: a single post would trigger 100M cache writes, saturating the timeline-cache cluster and adding seconds of write latency. Pure fanout-on-read (compute the timeline by merging all followee posts at query time) doesn't work either — it requires a sorted merge of N posts across hundreds of shards for every read, and reads dominate.

The industry-standard answer is a hybrid: ordinary users (followers below ~10K) get fanout-on-write — their posts are pushed to follower timelines at post time. Celebrities (followers above the threshold) get fanout-on-read — their posts are NOT pushed; instead, every reader's timeline service merges precomputed-cache entries with a small list of 'celebrities I follow' fetched live at read time. The threshold is tuned so the per-post fanout cost stays bounded and per-read overhead stays small (typical reader follows <10 celebrities, so the merge is cheap).

Second tradeoff: timeline ordering. Strict reverse-chronological is simple but produces a noisy timeline at scale. Most production systems rank by a learned score (recency × engagement × relevance) computed offline and refreshed every few minutes — discussing this signals you understand the ML/serving split, even if your v1 ships pure recency. Third: deletion. When a user deletes a post, the post row flips a tombstone but timeline-cache entries are typically not purged eagerly — readers filter tombstoned post_ids at read time. This trades a tiny extra read-time cost for avoiding O(followers) delete work.

Common mistakes

• Defaulting to fanout-on-write without acknowledging the celebrity problem — the interviewer will push back within 5 minutes
• Storing media bytes in the same store as post metadata; this kills storage cost and read latency
• Treating the home timeline as a live SQL query joining posts + follows — works at 10K users, blows up at 10M
• Ignoring the read-to-write ratio when sizing infrastructure — over-provisioning the write path while the read path melts under load
• Forgetting cache-key choice: timeline cache sharded by user_id (correct) vs by post_id (wrong — fragments per-user reads across shards)

Likely follow-up questions

• How would your design handle a 10× growth in DAU?
• What changes if posts could be 10 MB video instead of 280 chars of text?
• How would you add a 'For You' algorithmic feed without breaking the existing chronological one?
• How would you ensure tweets from a user the reader just followed appear immediately, before the next fanout sweep?
• How would you make replies and retweets show up in the right person's timeline correctly?