The Question
Design

Design a High-Scale Social Media Feed System

Design a global-scale social media platform similar to Twitter. The system must support posting short-form content, a following mechanism, and a chronological home timeline for 300 million daily active users. Focus specifically on the architectural trade-offs between push-based and pull-based feed delivery, handling celebrity accounts with massive follower counts, and ensuring sub-second latency for timeline retrieval under peak loads of 100,000+ QPS. Discuss how you would ensure high availability and eventual consistency in a multi-region deployment.
Cassandra
Redis
Kafka
S3
PostgreSQL
CDN
Kubernetes
gRPC
Questions & Insights

Clarifying Questions

Scale and Traffic: What is the expected Daily Active Users (DAU) and the average number of tweets per user per day? (Assumption: 300M DAU, 2 tweets/day per user, 600M total tweets/day).
Read/Write Ratio: Is the system read-heavy or write-heavy? (Assumption: Heavily read-biased, 100:1 ratio, focusing on timeline consumption).
Content Types: Should the MVP support media (images/videos) or just text? (Assumption: Text and simple image/video uploads).
Timeline Strategy: Is the timeline strictly chronological or algorithmic? (Assumption: Strictly reverse-chronological for MVP simplicity).
Consistency vs. Availability: Is it acceptable for a tweet to take a few seconds to appear on a follower's timeline? (Assumption: High Availability (AP) over Strong Consistency).

Thinking Process

Core Bottleneck: The primary challenge is the "Fan-out" process—how to efficiently deliver a single tweet to millions of followers' timelines without high latency.
Progressive Logic:
How do we store tweets and follows efficiently?
How do we build a user's home timeline (Pull vs. Push)?
How do we handle "Celebrity" users with millions of followers (The Thundering Herd problem)?
How do we scale the read path to handle 30B+ views per day?

Bonus Points

Hybrid Fan-out Strategy: Use a "Push" model for regular users (pre-compute timelines) and a "Pull" model for celebrities to prevent MQ congestion and storage explosion.
Cell-Based Architecture: Partitioning users into isolated "cells" (shards of infrastructure) to limit the blast radius of service failures.
Social Graph Optimization: Using a specialized graph database or highly optimized adjacency lists in NoSQL (e.g., Cassandra) to handle follow-relationships.
Edge Side Rendering/Caching: Using CDNs not just for media, but for caching localized "Top Tweets" to reduce origin load.
Design Breakdown

Functional Requirements

Core Use Cases:
Users can post tweets (text/media).
Users can follow other users.
Users can view a "Home Timeline" (tweets from people they follow).
Users can view a "User Timeline" (their own tweets).
Scope Control:
In-Scope: Tweeting, Following, Home Timeline, User Timeline.
Out-of-Scope: Search, Trending Topics, Direct Messages, Retweets/Replies (simplified as tweets), Ads.

Non-Functional Requirements

Scale: Support 300M DAU and 100k+ QPS for writes, 10M+ QPS for reads.
Latency: Timeline generation < 200ms; Tweet post to appearance < 2 seconds.
Availability & Reliability: 99.99% availability (Highly Available).
Consistency: Eventual consistency is acceptable for timeline updates.
Fault Tolerance: System must survive regional outages or data center failures.
Security: OAuth2 for AuthN, private vs. public profile visibility.

Estimation

Traffic Estimation:
Write QPS (Tweets): 600M / 86400 \approx 7,000 avg; 14,000 peak.
Read QPS (Timeline): 300M \times 10 \text{ views} / 86400 \approx 35,000 avg; 100,000+ peak.
Storage Estimation:
600M tweets/day. Text (280 chars) \approx 1KB with metadata.
600GB/day for text. 600GB \times 365 \approx 220TB per year.
Media: If 10% tweets have images (1MB), 60M \times 1MB = 60TB/day.
Bandwidth Estimation:
Ingress: 60TB/day \approx 700MB/s.
Egress: Read bias 100x \approx 70GB/s (mostly served via CDN).

Blueprint

Concise Summary: A microservices-based architecture utilizing a hybrid Fan-out model. Tweets are persisted in a write-optimized NoSQL store, while timelines are pre-computed and stored in an in-memory cache for ultra-low latency.
Major Components:
Tweet Service: Handles incoming tweet writes and metadata persistence.
Follow Service: Manages the social graph (follow/unfollow).
Fan-out Workers: Asynchronously propagates tweets to followers' cached timelines.
Timeline Service: Aggregates and serves the home/user timelines from cache.
Redis Timeline Cache: Stores pre-computed timelines for active users.
Simplicity Audit: This design avoids complex graph processing engines for the MVP and relies on Redis for fast reads, which is the industry standard for high-performance feed systems.
Architecture Decision Rationale:
Why this architecture?: The Push model (Fan-out) ensures that the complex work of "joining" follows and tweets happens at write-time, making the read-path (the most frequent operation) extremely fast.
Functional Satisfaction: Covers the full lifecycle from tweet creation to consumption.
Non-functional Satisfaction: Scalable via horizontal sharding and highly available via asynchronous processing.

High Level Architecture

Sub-system Deep Dive

Edge (Optional)

Content Delivery & Traffic Routing:
CDN: Cloudfront or Akamai used for caching media (images/videos) and static assets.
Load Balancer: L7 Load Balancer (NGINX/Envoy) for SSL termination and path-based routing to services.
Security & Perimeter:
API Gateway: Handles Authentication (JWT/OAuth2) and Rate Limiting (preventing bot spamming).

Service

Topology & Scaling:
Stateless services deployed on Kubernetes (EKS/GKE) across multiple Availability Zones.
Auto-scaling based on CPU and Request Count.
API Schema Design:
POST /v1/tweets: { text, media_ids }. Protocol: REST.
GET /v1/timeline/home: Returns list of Tweet objects. Protocol: REST/gRPC.
POST /v1/follow/{userId}: Idempotent follow action.
Resilience:
Retries with exponential backoff for Fan-out workers.
Circuit breakers on the Timeline service to fallback to "User Timeline" only if "Home Timeline" cache is down.

Storage

Access Pattern:
Tweet DB: High write, High read (by ID).
Social Graph DB: High read (get followers), Moderate write.
Database Table Design:
Tweets (Cassandra): Partitioned by user_id, Clustering Key tweet_id (TimeUUID). This allows fast retrieval of a user's tweets.
Follows (PostgreSQL): follower_id, followee_id, created_at. Indexed on both IDs.
Technical Selection:
Cassandra: Chosen for Tweet DB due to high write throughput and easy horizontal scaling.
S3: Object storage for media files.

Cache

Purpose: Pre-computed "Home Timelines" to avoid expensive SQL joins at read time.
Key-Value Schema:
Key: TL:{user_id}, Value: List of tweet_ids.
TTL: 72 hours (only for active users).
Failure Handling: If Redis is cold, Timeline Service falls back to "Pull" model (querying Follow DB + Tweet DB), though with higher latency.

Messaging

Purpose: Decouples the Tweet Service from the expensive Fan-out process.
Event Schema: { tweet_id, author_id, timestamp }.
Throughput: Kafka handles the 7k-14k QPS. Partitioned by author_id to ensure ordering for a single user's tweets.
Technical Selection: Kafka for its high durability and ability to replay events if fan-out workers fail.

Data Processing

Processing Model: Fan-out workers are the core "Multi-Process" component.
Logic:
Fetch all followers of author_id from Social Graph DB.
For each follower, update their list in Redis Timeline Cache.
Celebrity Handling: If followers > 100k, do NOT push. Instead, flag the author as a "celebrity".
Technical Selection: Go/Rust workers for high-concurrency processing.
Wrap Up

Advanced Topics

Trade-offs (The Celebrity Problem):
A "Pure Push" model breaks for celebrities (e.g., 100M followers = 100M Redis writes per tweet).
Optimization: Use a Hybrid Model. When a user views their timeline, the service fetches the pre-computed "Push" cache AND pulls recent tweets from any "celebrities" they follow, merging them on the fly.
Reliability:
Use Dead Letter Queues (DLQ) in Kafka for tweets that fail to fan-out.
Bottleneck Analysis:
Hot Shards: High-traffic tweets (e.g., viral content) can stress specific Cassandra nodes. Use a "Social Cache" for the tweets themselves (not just timelines) to offload DB reads.
Security:
Implement "Block" functionality at the Fan-out layer to ensure blocked users don't see content.