Requirements

Functional Requirements:

• Allow users to tweet messages up to 140 characters.
• Enable users to follow other users.
• Allow users to like tweets from other users.
• Display tweets from followed users in the home feed.
• Show top K popular tweets in the home feed based on likes and followers.
• View user information and their tweets

Non-Functional Requirements:

• High availability: 99.99% uptime
• Low Latency: timeline loads in <500ms, tweets post in <1s
• Scalability, Handle massive read heavy workloads
• Eventual Consistency: timelines can be slightly stale which is an acceptable tradeoff
• Durability, tweets must never be lost

API Design

POST /v1/tweets

request: {

"user_id": "123",

"content": "Hello Twitter!",

"media_ids": ["m1", "m2"]

}

Response: {

"tweet_id": "t456",

"created_at" "2026-02-02T10:00:00:00Z"

}

POST /v1/tweets/{tweet_id}/like

Request: { "user_id": 123" }

Response: {"success": true }

POST /v1/users/{user_id}/follow

Request: {"follower_id": "123"}

Response: {"success: true}

GET /v1/timeline/home?user_id=123?cursor=abc?limit=20

Response: {

"tweets": [

{

"tweet_id": "t789",

"user_id": "456",

"username": "john doe",

"content": "...",

"created_at": "...",

"likes_count": 100,

"retweets_count": 50

}

],

"next_cursor": "xyz"

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

1. API Gateway / Load Balancer

Purpose: Entry point for all client requests

Responsibilities:

• Route requests to appropriate services
• SSL termination
• Rate limiting (prevent abuse)
• Authentication/Authorization (JWT tokens)
• Request validation

2. Tweet Service

Purpose: Handle all tweet-related operations

Key Functions:

• Post Tweet: Validate, save tweet, trigger fanout
• Get Tweet: Retrieve single tweet by ID
• Like Tweet: Increment like counter
• Delete Tweet: Remove tweet and invalidate caches

Responsibilities:

• Business logic for tweets
• Validation (280 char limit, spam detection)
• Coordinate with other services
• Emit events to message queue

3. Timeline Service

Purpose: Generate and serve user timelines

Key Functions:

• Get Home Timeline: Return tweets from followed users
• Get User Timeline: Return specific user's tweets
• Cache Management: Keep timelines hot in Redis

Responsibilities:

• Implement fanout logic (hybrid approach)
• Merge celebrity tweets on-demand
• Hydrate tweet data (batch fetch from Tweet DB)
• Cursor-based pagination

4.Tweet Database (Cassandra)

Purpose: Persistent storage for all tweets

Why Cassandra?

• ✅ Massive write throughput (2,300+ TPS)
• ✅ Horizontal scalability (add nodes easily)
• ✅ High availability (replication)
• ✅ Time-series data friendly (tweets by timestamp)

5. Timeline Cache (Redis)

Purpose: Fast in-memory storage for pre-computed timelines

Why Redis?

• ✅ Sub-millisecond latency
• ✅ Sorted Sets (ZSET) perfect for timelines
• ✅ TTL support (auto-expire old data)
• ✅ Distributed clustering

Data Structure:

Cache Strategy:

• Store top 1000 tweets per user
• TTL: 1 hour
• Lazy refresh on cache miss

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

. API Gateway / Load Balancer

Purpose: Entry point for all client requests

Responsibilities:

• Route requests to appropriate services
• SSL termination
• Rate limiting (prevent abuse)
• Authentication/Authorization (JWT tokens)
• Request validation

2. Tweet Service

Purpose: Handle all tweet-related operations

Key Functions:

• Post Tweet: Validate, save tweet, trigger fanout
• Get Tweet: Retrieve single tweet by ID
• Like Tweet: Increment like counter
• Delete Tweet: Remove tweet and invalidate caches

Responsibilities:

• Business logic for tweets
• Validation (280 char limit, spam detection)
• Coordinate with other services
• Emit events to message queue

3. Timeline Service

Purpose: Generate and serve user timelines

Key Functions:

• Get Home Timeline: Return tweets from followed users
• Get User Timeline: Return specific user's tweets
• Cache Management: Keep timelines hot in Redis

Responsibilities:

• Implement fanout logic (hybrid approach)
• Merge celebrity tweets on-demand
• Hydrate tweet data (batch fetch from Tweet DB)
• Cursor-based pagination

4.Tweet Database (Cassandra)

Purpose: Persistent storage for all tweets

Why Cassandra?

• ✅ Massive write throughput (2,300+ TPS)
• ✅ Horizontal scalability (add nodes easily)
• ✅ High availability (replication)
• ✅ Time-series data friendly (tweets by timestamp)

5. Timeline Cache (Redis)

Purpose: Fast in-memory storage for pre-computed timelines

Why Redis?

• ✅ Sub-millisecond latency
• ✅ Sorted Sets (ZSET) perfect for timelines
• ✅ TTL support (auto-expire old data)
• ✅ Distributed clustering

Data Structure:

Cache Strategy:

• Store top 1000 tweets per user
• TTL: 1 hour
• Lazy refresh on cache miss

Fanout-on-Write vs Fanout-on-Read

Fanout-on-Write:

• ✅ Fast reads (pre-computed)
• ✅ Simple read logic
• ❌ Slow writes (write amplification)
• ❌ Wasted work if timeline never viewed
• Best for: Users with <1M followers

Fanout-on-Read:

• ✅ Fast writes (no amplification)
• ✅ Always fresh data
• ❌ Slow reads (compute on demand)
• ❌ Complex merge logic
• Best for: Celebrities (>1M followers)

Chosen: Hybrid approach balances both

SQL vs NoSQL for Tweets

SQL (PostgreSQL):

• ✅ ACID guarantees
• ✅ Rich queries (JOIN, aggregations)
• ❌ Harder to shard horizontally
• ❌ Write bottleneck at scale

NoSQL (Cassandra):

• ✅ Massive horizontal scalability
• ✅ High write throughput
• ✅ Eventual consistency acceptable
• ❌ Limited query flexibility
• Chosen: Cassandra for tweets (write-heavy, simple queries)

Push vs Pull for Timeline Updates

Push (Fanout-on-write):

• Pre-compute timelines when tweets posted
• Chosen for regular users

Pull (Fanout-on-read):

• Compute timelines on-demand
• Chosen for celebrities