Design Twitter Newsfeed

Requirements to pin down first

• Functional: post a tweet (text up to 280 characters, optional media), follow and unfollow, view a home timeline of tweets from followed accounts, view a user's own profile timeline.
• Non-functional: timeline loads in under 200 ms at p99; a new tweet appears in followers' timelines within about 5 seconds; very high availability; eventual consistency is acceptable for timelines.
• Clarify: chronological or ranked timeline, and whether search, trends, and notifications are in scope (usually not in a 45-minute round).

Capacity estimates

Reads outnumber posts about 20 to 1, and the fan-out multiplies writes by about 200. The design question is where to pay that cost: at write time, at read time, or a mix.

API

POST   /api/v1/tweets                 { text, mediaIds[] } -> { tweetId }
GET    /api/v1/timeline/home?cursor=  -> { tweets[], nextCursor }
GET    /api/v1/users/{id}/tweets?cursor=
POST   /api/v1/users/{id}/follow
DELETE /api/v1/users/{id}/follow

Data model

• tweets (tweet_id PK, author_id, text, media_ids, created_at): sharded by tweet_id, which is a Snowflake ID so it is time-sortable.
• user_tweets (author_id, tweet_id): a per-author index used for profile pages and for pulling celebrity tweets, sharded by author_id.
• follows (follower_id, followee_id) stored twice, once keyed by follower and once by followee, so both who do I follow and who follows me are single-partition reads.
• home timeline cache: a Redis list per user holding the latest 800 tweet IDs, trimmed on insert.
• media: images and video in object storage, served through a CDN.

How posting and reading work, step by step

1. The Tweet service validates the post, assigns a Snowflake ID, writes it to the tweets store, and publishes a TweetCreated event to Kafka.
2. Fan-out workers consume the event and fetch the author's follower list in pages of a few thousand.
3. For a normal author (say under 10,000 followers), workers LPUSH the tweet ID into each active follower's Redis timeline and LTRIM it to 800 entries. Inactive users are skipped; their timelines are rebuilt when they return.
4. For a celebrity author, workers skip the fan-out entirely; the tweet only lands in the author's own user_tweets index.
5. When a user opens the app, the Timeline service reads their cached list of IDs, then fetches recent tweets from the few celebrities they follow and merges both lists by ID, which sorts by time.
6. It hydrates the IDs into full tweets through a tweet cache (author name, text, counts), applies filters such as blocks and deleted tweets, and returns a page with a cursor.

Why hybrid fan-out wins

Pure push means one post from an account with 50 million followers triggers 50 million cache writes, delaying delivery for minutes and spiking load. Pure pull means every timeline read queries hundreds of authors' recent tweets and merges them, which is far too slow at 70,000 reads per second. Hybrid fan-out pushes for the 99%+ of authors with modest audiences and pulls for the small set of celebrities, so each read merges one precomputed list with a handful of celebrity lists. The deeper mechanics of the queue between posting and fan-out are covered in message queues.

Common mistakes in interviews

• Querying SELECT ... WHERE author_id IN (followees) ORDER BY created_at on every timeline load.
• Choosing pure fan-out on write and never addressing celebrity accounts.
• Fanning out full tweet bodies instead of IDs, which multiplies storage and makes edits and deletes painful.
• Ignoring inactive users, who account for a large share of follower lists and waste fan-out work.
• Forgetting pagination with stable cursors; offset pagination breaks when new tweets arrive at the top.

Interview questions