The Question
Design

Design a Scalable Social Media Feed System (Twitter/X)

Design a social media platform similar to Twitter that supports 300 million daily active users. The system must allow users to post tweets, follow others, and view a real-time home timeline. Focus specifically on the challenges of high read-to-write ratios, the 'fan-out' problem for celebrity accounts, and achieving sub-200ms timeline delivery latency. Discuss the trade-offs between push and pull models for feed generation and how to handle data consistency and partitioning at scale.
Cassandra
PostgreSQL
Redis
Kafka
CDN
Kubernetes
gRPC
Object Storage
Questions & Insights

Clarifying Questions

Scale: What is the target Daily Active User (DAU) count and the write/read ratio?
Assumption: 300M DAU, 500M tweets/day (write), and 60B timeline views/day (read). This implies a high read-to-write ratio (120:1).
Functionality: Are features like Search, Trends, and Direct Messaging (DMs) in scope for the MVP?
Assumption: No. The MVP focuses on posting tweets, following users, and viewing the Home/User timelines.
Media: Do we need to support high-resolution video and images?
Assumption: Yes, but storage is handled via Object Storage (S3), and the metadata is part of the tweet object.
Fan-out Logic: How should we handle "Celebrity" accounts (users with millions of followers)?
Assumption: Use a hybrid approach. Push-model for regular users and Pull-model (on-demand merge) for celebrities to avoid the "herd effect" and write amplification.

Thinking Process

Core Bottleneck: The primary challenge is the Fan-out process. Delivering a single tweet to millions of followers' timelines in near real-time requires a massive asynchronous processing pipeline.
Progressive Questions:
How do we store tweets and followers to ensure fast retrieval?
How do we update millions of timelines without blocking the user who just tweeted?
How do we optimize for celebrities whose fan-out would overwhelm the system?
How do we serve the pre-computed home timeline with sub-200ms latency?

Bonus Points

Hybrid Fan-out: Implementing a threshold (e.g., 5k followers) where the system switches from "Push" (writing to follower caches) to "Pull" (merging at read-time) to prevent system hotspots.
Cell-based Architecture: Partitioning users into "cells" or "shards" to limit the blast radius of infrastructure failures and simplify global scaling.
Time-series Optimization: Using specialized NoSQL storage (e.g., Cassandra or DynamoDB) with clustering keys ordered by timestamp for efficient range queries on timelines.
Tail Latency Management: Using "Selective Fan-out" and caching strategies to ensure the 99th percentile (p99) latency remains low even during viral events.
Design Breakdown

Functional Requirements

Core Use Cases:
Users can post text-based tweets (up to 280 characters).
Users can follow/unfollow other users.
Users can view a "Home Timeline" (posts from people they follow).
Users can view a "User Timeline" (posts by a specific user).
Scope Control:
In-scope: Tweeting, Following, Home Timeline, User Timeline.
Out-of-scope: Search, Retweets, Likes, Trends, Ads, Direct Messages.

Non-Functional Requirements

Scale: Support 300M DAU and 10k+ QPS for writes, 1M+ QPS for reads.
Latency: Under 200ms for timeline loading; under 500ms for tweet delivery to followers.
Availability & Reliability: 99.99% availability; tweets must not be lost once acknowledged.
Consistency: Eventual consistency is acceptable for timelines (it is okay if a tweet takes a few seconds to appear to all followers).
Fault Tolerance: System must survive the failure of a single data center or cache cluster.

Estimation

Traffic Estimation:
Write QPS: 500M tweets / 86400s ≈ 6,000 QPS.
Read QPS (Timeline): 60B views / 86400s ≈ 700,000 QPS.
Storage Estimation:
500M tweets/day * 1KB per tweet ≈ 500GB/day.
180TB per year (excluding media).
Bandwidth Estimation:
Outgoing: 700k reads/sec * 10KB (avg timeline size) ≈ 7GB/s.

Blueprint

Concise Summary: A hybrid fan-out architecture where most timelines are pre-computed and stored in an in-memory cache (Redis), while celebrity tweets are merged at read-time to optimize write performance.
Major Components:
Tweet Service: Handles incoming tweet writes and metadata storage.
Fan-out Service: Asynchronously pushes tweet IDs to the Redis caches of active followers.
Social Graph Service: Manages follower/following relationships using a relational database with heavy caching.
Timeline Service: Fetches pre-computed timelines from Redis and merges them with celebrity tweets on-the-fly.
Simplicity Audit: This architecture avoids complex graph databases for the MVP, using a standard Relational DB for social links and Redis for high-speed timeline delivery.
Architecture Decision Rationale:
Why this architecture?: The Push model handles the 99% case of users with few followers, ensuring instant reads. The Pull model handles the 1% "Celebrity" case, preventing write-side bottlenecks.
Functional Satisfaction: Covers the full lifecycle from tweet creation to timeline consumption.
Non-functional Satisfaction: Redis provides sub-millisecond latency for reads, while Kafka decouples writes from timeline updates for high availability.

High Level Architecture

Sub-system Deep Dive

Edge (Optional)

Content Delivery & Traffic Routing: Static assets (media) are served via CDN (Cloudfront/Akamai). DNS uses latency-based routing to direct users to the nearest regional data center.
Security & Perimeter: API Gateway handles JWT-based Authentication, TLS termination, and Rate Limiting (e.g., 100 tweets per hour per user) to prevent spam.

Service

Topology & Scaling: Stateless microservices deployed in Kubernetes across multiple Availability Zones (AZs). Scaling is based on CPU and Request Count.
API Schema Design:
POST /v1/tweets: { content: string, media_ids: list }. Returns tweet_id.
GET /v1/timeline/home: Returns list of Tweet objects. Supports cursor-based pagination.
POST /v1/users/{id}/follow: Idempotent operation to follow a user.
Resilience: Fan-out workers use exponential backoff for Redis writes. Timeline service uses a fallback to "User Timeline" merge if the pre-computed Redis cache is cold/missing.

Storage

Access Pattern:
Tweet DB: High write, high read by ID/Author.
Social Graph DB: High read (find followers), moderate write (follow/unfollow).
Database Table Design:
Tweets Table (NoSQL - Cassandra): Partition Key: author_id, Clustering Key: tweet_id (TimeUUID). This allows fast retrieval of a user's own tweets.
Followers Table (PostgreSQL): user_id (PK), follower_id (PK). Indexed on both columns for bi-directional lookups.
Technical Selection: Cassandra for Tweets due to its high-write throughput and linear scalability. PostgreSQL for Social Graph due to relational integrity requirements for follower counts and relationships.

Cache

Purpose & Justification: Pre-computed Home Timelines are stored in Redis to meet the <200ms latency requirement.
Key-Value Schema:
Key: tl:{user_id}, Value: List of TweetIDs.
TTL: 72 hours for active users; inactive users' caches are evicted and rebuilt on login.
Failure Handling: If Redis is unavailable, the system falls back to a "Pull" model, querying the Social Graph and Tweet DB directly (slower, but functional).

Messaging

Purpose & Decoupling: Kafka decouples the Tweet Service from the Fan-out Worker. This ensures that even if the fan-out process is slow, the user's "Post Tweet" request finishes quickly.
Throughput & Partitioning: Partitioned by author_id to ensure that tweets from the same user are processed in order.
Technical Selection: Kafka for its high throughput and durability.

Data Processing

Processing Model: The Fan-out Worker (Multi-process) pulls from Kafka.
Logic: For a given tweet_id and author_id:
Fetch all follower_ids from Social Graph Service.
For each follower, update tl:{follower_id} in Redis.
If follower_count > 5000, mark author as "Celebrity" and skip push fan-out.
Technical Selection: Custom Golang workers for low-latency concurrent processing.
Wrap Up

Advanced Topics

Trade-offs (Push vs Pull):
Push: Fast reads, slow/expensive writes. Best for most users.
Pull: Fast writes, slow/complex reads. Best for celebrities.
Hybrid: Complexity increases but ensures the system doesn't crash when a celebrity tweets.
Reliability: If the Fan-out worker lags, users see delayed tweets. We monitor "Kafka Lag" as a primary health indicator.
Bottleneck Analysis: The "Hot follower" (user following 5k+ people) results in a large Redis list. We cap the pre-computed timeline at 800-1000 TweetIDs.
Security: Data is encrypted at rest in Cassandra. mTLS is used for service-to-service communication.