System Design: Twitter Feed

The Twitter home feed is the canonical fan-out problem. Millions of writers, hundreds of millions of readers, and an expectation that new tweets show up within seconds. This post walks through a design that handles the core load and the well known edge cases.

What and why

A home feed shows you a reverse chronological (or ranked) stream of tweets from accounts you follow. Reads dominate writes by roughly a thousand to one. The same tweet may need to appear in hundreds of millions of timelines. Doing that naively, either on every read or on every write, will not scale.

The goal is to make timeline reads cheap and predictable while keeping write amplification bounded. Everything in the design exists to balance those two forces.

Mental model

Imagine two extreme strategies. In pure fan-out on write, every new tweet is copied into the inbox of each follower at post time. Reads are then trivial (just fetch your inbox), but a celebrity post triggers tens of millions of writes. In pure fan-out on read, tweets stay only with their author and the feed is assembled by querying every followed account at read time. Writes are cheap but reads are expensive and slow.

Real systems live in the middle. They fan out for normal users, leave celebrity tweets in place, and merge the two at read time. That hybrid is the heart of the design.

Architecture

The baseline separates the write path (accept tweet, fan out) from the read path (assemble timeline, rank, return).

Write path:
user -> API -> tweet store
            -> fan-out worker -> follower inboxes (Redis)
            [skip fan-out if author is a celebrity]

Read path:
user -> timeline service
          -> inbox (precomputed tweets)
          -> celebrity tweets (pull at read time)
          -> merge + rank -> response

A new tweet is written to a durable tweet store and then handed to a fan-out worker. The worker looks up the author’s followers and pushes the tweet id into each follower’s inbox cache. If the author exceeds a follower threshold (say, a million), fan-out is skipped and their tweets are pulled at read time instead.

The timeline service fetches the inbox, pulls recent tweets from any celebrities the user follows, merges the two lists, applies ranking, hydrates with tweet content from cache, and returns. Most timeline reads stay entirely in memory.

Trade-offs

The first trade-off is the celebrity threshold. Too low, and you push too much work onto read time and slow down popular users’ followers. Too high, and a single viral account can saturate the fan-out workers. The threshold is usually tuned per region and reviewed regularly.

The second is inbox storage. Storing full tweet objects per follower is fast but expensive. Storing only tweet ids and hydrating from a shared tweet cache trades a small read latency hit for much lower storage cost. Most systems store ids.

The third is ranking versus pure chronology. Chronological feeds are predictable and cheap; ranked feeds drive engagement but require feature pipelines and model serving in the hot path. A pragmatic compromise is to rank within recent windows and keep older content chronological.

Practical tips

Cap inbox length aggressively. Most users only ever read the first few hundred tweets in their timeline; storing a thousand is plenty and saves enormous amounts of memory. Older tweets can always be fetched from the tweet store on demand.

Make fan-out idempotent and resumable. Workers crash, partitions move, and a duplicate tweet in someone’s inbox is far worse than a brief delay. Use the tweet id as a deduplication key.

Measure end-to-end latency from tweet creation to follower visibility, not just per-component metrics. That single number captures the user experience and surfaces problems that internal dashboards miss.

Wrap-up

A Twitter style feed is a study in asymmetry: rare expensive writes funding cheap frequent reads, with carefully chosen exceptions for users who break the average. The hybrid fan-out pattern, an inbox cache, and a small celebrity carve-out together handle the vast majority of the load. Ranking and personalization sit on top of that foundation, not under it.