System Design Interview: Designing Twitter Feed, WhatsApp & YouTube Architecture

The System Design Interview Framework

System design interviews test your ability to break down ambiguous requirements, identify bottlenecks, and make justified trade-offs. Every strong answer follows this structure: Clarify → Estimate → Design → Deep Dive → Trade-offs.

1. Design Twitter's News Feed

Scale Numbers

Writes: 5M tweets/day = ~60 QPS (peak 3x = 180 QPS)
Reads:  600M/day      = ~7,000 QPS (peak = 21,000 QPS)
Storage: avg tweet = 280 chars = ~1 KB
         5M * 1 KB = 5 GB/day => ~1.8 TB/year (text only)
         Images:  ~30% of tweets, avg 500 KB
                  1.5M * 500 KB = 750 GB/day => CDN required

Feed Generation: Pull vs Push vs Hybrid

Twitter's Hybrid Approach

1. When a tweet is posted, push to all followers who have fewer than 10K followers (regular users).
2. For celebrities (10K+ followers), do not pre-push. Fetch their latest tweets at read time and merge.
3. Timelines stored in Redis (sorted set by timestamp), capped at 800 tweets.

@celery_app.task
def fanout_tweet(tweet_id: str, author_id: str):
    tweet = Tweet.objects.get(id=tweet_id)
    followers = Follower.objects.filter(followee_id=author_id).values_list('follower_id', flat=True)

    pipe = redis.pipeline(transaction=False)
    for follower_id in followers:
        if get_follower_count(follower_id) < 10_000:
            timeline_key = f"timeline:{follower_id}"
            pipe.zadd(timeline_key, {tweet_id: tweet.created_at.timestamp()})
            pipe.zremrangebyrank(timeline_key, 0, -801)  # Keep only latest 800
    pipe.execute()

2. Design WhatsApp Messaging

Core Challenges

• Message ordering: Messages must arrive in order within a conversation
• Delivery guarantees: At-least-once, exactly-once, or at-most-once?
• Presence: Online/offline, last seen, typing indicators
• End-to-end encryption: Server never sees plaintext

Message Delivery States

WhatsApp uses a 3-state model: SENT (single tick), DELIVERED (double tick), READ (blue double tick). Each state requires an ACK from the recipient back to the sender.

CREATE TABLE messages (
    id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    chat_id     UUID NOT NULL REFERENCES chats(id),
    sender_id   UUID NOT NULL,
    content     BYTEA NOT NULL,           -- encrypted blob
    seq_num     BIGINT NOT NULL,          -- monotonic per chat
    status      SMALLINT DEFAULT 0,       -- 0=sent, 1=delivered, 2=read
    created_at  TIMESTAMPTZ DEFAULT NOW(),
    UNIQUE (chat_id, seq_num)             -- ordering guarantee
);
CREATE INDEX idx_messages_chat_seq ON messages(chat_id, seq_num DESC);

3. Design YouTube's Video Pipeline

The Two Hard Problems

1. Upload and transcoding: A 4K 30-minute video is ~12 GB. Transcode into 8 quality levels (360p through 4K) in parallel.
2. Adaptive bitrate streaming: Serve the right quality based on bandwidth, switching seamlessly mid-stream.

Client -> Upload Service (resumable chunked upload)
               |
         Raw Video Storage (S3/GCS)
               |
     Transcoding Job Queue (SQS/Kafka)
               |
     Transcoding Workers (FFmpeg, GPU farm)
       /          |          \
  360p.mp4  720p.mp4  1080p.mp4  ... (8 variants)
               |
    CDN (CloudFront/Akamai)
               |
         Client (HLS/DASH adaptive streaming)

# master.m3u8 — tells the player which variants exist
#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360
360p/playlist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2800000,RESOLUTION=1280x720
720p/playlist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
1080p/playlist.m3u8

Key Distributed Systems Concepts

Interview tip: Don't just say "I'd use Redis for caching." Say "I'd use Redis with a TTL-based eviction policy, accepting eventual consistency in exchange for sub-millisecond read latency — the trade-off is appropriate because feed staleness of a few seconds is acceptable."