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:



Key: timeline:{user_id} Value: ZSET {tweet_id: timestamp} Operations: ZADD (insert), ZREVRANGE (get latest)

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:



Key: timeline:{user_id} Value: ZSET {tweet_id: timestamp} Operations: ZADD (insert), ZREVRANGE (get latest)

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