System Design: Twitter

One API server, one relational database. POST /api/tweets inserts a row; the home timeline is a query — select tweets from everyone I follow, order by time, limit 50. For a prototype with a thousand users this is completely correct.

Say the bottleneck out loud: every timeline load joins the follow graph against the tweets table. At ~500M tweets/day and users following ~200 accounts each, that join runs millions of times a second against constantly-growing tables. The read path collapses first, and it collapses hard.

Flip the work to the write path. When a tweet lands, publish it to Kafka; a fan-out service reads it and pushes the tweet ID into a Redis-cached timeline list for each follower. Now the home timeline API is a single cache read — comfortably under the ~300ms budget.

The write amplification is real but affordable for normal users: 200 followers means ~200 cheap list pushes, on the order of ~2M fan-out operations/s platform-wide. Kafka absorbs the burst; the fan-out workers scale horizontally and can lag a few seconds without anyone noticing — timelines are explicitly eventually consistent.

Then someone with ~100M followers tweets, and your fan-out service owes ~100M cache writes for one 280-character message. Storms of these back up Kafka and delay everyone's timeline. Pure push does not survive a skewed follower distribution.

The interview-winning move is the hybrid: fan out on write for normal accounts, but for high-follower accounts, skip fan-out entirely and pull their recent tweets at read time, merging them into the reader's cached timeline. Each user pays a small merge cost for the handful of celebrities they follow — bounded work on both paths.

The timeline cache holds IDs, not content. Tweet bodies go to a write-optimized wide-column store (Cassandra-style) partitioned by tweet ID — billions of rows, ~250 GB/day of text, with old partitions tiered to cold storage. Media never touches this path: uploads go through a separate pipeline that transcodes and serves via CDN, with the tweet storing only media IDs.

Search and trends hang off the same Kafka stream that feeds fan-out: an indexer writes into Elasticsearch/OpenSearch for keyword queries, and a streaming aggregator counts hashtag velocity for trending topics. Nothing about search sits on the tweet-publish critical path.

A moderation service consumes the tweet stream too: ML models score every tweet for spam and abuse, high-confidence cases are actioned automatically, and the ambiguous middle flows to a human review tool. Every action lands in an audit log — GDPR deletes and provenance requirements make this non-optional, and raising it unprompted reads as senior.

Notifications (~50K events/s for likes, replies, mentions) are one more Kafka consumer feeding a push service that fronts APNs/FCM. The finished shape is one durable event stream with independent consumers — fan-out, search, moderation, notifications — each of which can lag or fail without touching tweet publish latency.