Loading…

Requirements

Functional: post a short text update ("tweet"); follow/unfollow; view a home timeline of tweets from followed accounts; view a single user's own timeline. Non-functional: timeline reads must be fast at massive read ratios (far more people read tweets than post them); the system must tolerate retweets and replies without duplicating storage.

Data model: don't duplicate tweet content

A retweet should reference the original tweet, not copy its text — otherwise editing/deleting the original (or measuring its real engagement) becomes inconsistent across every copy.

Step 1 / 3

The original tweet is stored once, as the single source of truth.

Design a Twitter-Style Timeline

Requirements

This is structurally the same fan-out problem as Instagram's feed

The core tradeoff (fan-out on write vs. fan-out on read, hybrid for high-follower accounts) is identical to the Instagram Feed problem — see that problem's diagram for the full walkthrough. What's genuinely different for Twitter is the data model, because of retweets and replies.

Data model: don't duplicate tweet content

A retweet should reference the original tweet, not copy its text — otherwise editing/deleting the original (or measuring its real engagement) becomes inconsistent across every copy.

Step 1 / 3

The original tweet is stored once, as the single source of truth.

Follow-up: how do you handle a reply thread efficiently?

Each tweet stores a parent_tweet_id, forming a tree. Rendering a full thread means walking that tree — for deep threads, this is usually capped and paginated rather than loaded all at once, since a viral thread can have tens of thousands of replies.