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

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10