You now have a useful pattern across the systems you've studied:
Spotify
↓
Streaming + CDN + Object Storage
Amazon
↓
Catalog + Inventory + Payment + Checkout
WhatsApp
↓
WebSocket + Ordering + Offline Sync + Messaging
Twitter
↓
Follow Graph + Fan-out + Feed + Ranking🐦 Twitter System Design — Interview Class Notes
Twitter/X is a classic social-media + fan-out system design problem.
The key challenge is:
A relatively small number of users create tweets, but millions of followers may need to see the same tweet quickly.
So the most important deep dive is:
⭐ News Feed + Fan-out
1. Problem Statement
Design a Twitter-like platform where users can:
Follow other users
Post tweets
View their home timeline
View a user's tweets
Upload photos/videos
Handle millions of users and tweets
Survive huge traffic spikes during global events
2. Three Core Assumptions ⭐
① Read-heavy or Write-heavy?
Read-heavy
Most users consume tweets rather than continuously creating them.
100 users
│
├── 90 users → Read tweets
│
└── 10 users → Post tweetsTherefore:
Twitter is predominantly read-heavy.
This becomes even more extreme when popular tweets are viewed by millions of users.
3. Distributed or Single Server?
Distributed system
A single server cannot handle:
Millions of users
Huge numbers of tweets
Timeline generation
Media
Global traffic
Celebrity accounts with millions of followers
We need horizontally scalable services.
4. Consistency or Availability?
⭐ Availability
Twitter can tolerate some eventual consistency.
For example, if a newly posted tweet takes a short time to appear in someone's timeline, that's usually acceptable.
But:
Twitter unavailable
↓
No timeline
↓
Poor user experienceTherefore:
Availability is more important than strict global consistency.
This doesn't mean consistency is irrelevant.
Tweet creation and durable storage must still be reliable.
5. Functional Requirements
Core Features
1. Follow Users
Following is one-directional.
Ramesh ─────follows────→ ElonIt does NOT automatically mean:
Elon ─────follows────→ RameshThis is an important distinction from a friendship model.
6. Post Tweet
Users can create tweets.
Example:
User
↓
Tweet Service
↓
Tweet DBTweet can contain:
Text
Photos
Videos
7. Home Timeline ⭐⭐⭐
This is the most important feature.
If Ramesh follows:
A
B
C
Dhis home timeline should contain tweets from:
A + B + C + Dordered/ranked appropriately.
Following
/ | \
A B C
\ | /
\ | /
Home Feed
↓
Ramesh8. User Timeline
A user should be able to see all/relevant tweets posted by a particular user.
Example:
twitter.com/userA
↓
User A's tweetsThis is different from the home timeline.
Home Timeline
Tweets from people I follow.
User Timeline
Tweets from one particular user.
9. Media Files
Tweets can contain:
Images
Videos
Large media shouldn't be stored directly inside the tweet database.
Use:
User
↓
Media Service
↓
Object Storage
↓
CDNTweet stores a reference:
tweet_id
media_id
media_type10. Non-Functional Requirements
① Availability ⭐⭐⭐
Twitter should remain available even if some servers fail.
② Low Latency
Timeline should load quickly.
User opens Twitter
↓
Timeline
↓
Fast responseA slow feed makes the application feel broken.
③ Reliability / Persistence
Tweets and uploaded media should not disappear.
Need:
Replication
Durable storage
Backups
Disaster recovery
④ Compatibility
Support:
Mobile
Desktop
Different screen sizes
Different operating systems
Different network conditions
⑤ Scalability
Must handle:
Normal day
↓
Major event
↓
Millions of additional requestsExamples:
Olympics
Oscars
Elections
Major sports events
Breaking news
11. Scope Questions ⭐
Before designing, ask:
Users
How many total users?
How many DAUs?
Tweets
How many tweets does an average user post per day?
Tweet size
What's the average tweet size?
Fan-out
⭐⭐⭐
How many followers does a typical user have?
And especially:
What is the maximum follower count?
This is extremely important.
A normal user might have:
100 followersA celebrity might have:
50M followersThese two cases require different strategies.
Peak traffic
What happens during global events?
Read/write ratio
Likely:
Reads >>> WritesReplication
What's the required replication factor?
12. High-Level Architecture ⭐⭐⭐
Start with this in an interview:
USERS
│
▼
┌─────────────┐
│ CDN / WAF │
└──────┬──────┘
│
▼
┌─────────────┐
│ API Gateway │
└──────┬──────┘
│
┌────────────────┼─────────────────┐
▼ ▼ ▼
User Service Tweet Service Feed Service
│ │ │
▼ ▼ ▼
User DB Tweet DB Feed Cache
│
▼
Kafka
│
┌─────────┴─────────┐
▼ ▼
Fan-out Workers Notification
│
▼
Feed Storage
Media
│
▼
Object Storage
│
▼
CDN13. The Most Important Concept — Fan-out ⭐⭐⭐⭐⭐
Suppose:
Ramesh
↓
posts tweetRamesh has:
1,000 followersWe need to make the tweet available to those followers' timelines.
This is called:
Fan-out
Tweet
│
┌────────┼────────┐
▼ ▼ ▼
Feed A Feed B Feed C
│ │ │
▼ ▼ ▼
User A User B User C14. Fan-out on Write
When the tweet is created:
User posts tweet
↓
Tweet Service
↓
Find followers
↓
Write tweet into follower feedsExample:
Ramesh posts T1
Followers:
A B C D E
Feed A ← T1
Feed B ← T1
Feed C ← T1
Feed D ← T1
Feed E ← T1Then when users open Twitter:
User
↓
Feed Cache
↓
Already prepared timelineAdvantage
Very fast reads.
Disadvantage
Expensive writes for users with millions of followers.
15. Fan-out on Read
Instead of pre-populating feeds:
User opens Twitter
↓
Find people they follow
↓
Fetch their tweets
↓
Merge
↓
Rank
↓
Return feedExample:
User follows:
A → tweets
B → tweets
C → tweets
D → tweets
↓
Merge
↓
Ranking
↓
Home FeedAdvantage
Tweet creation is cheap.
Disadvantage
Timeline reads become expensive.
16. The Twitter Solution — Hybrid Fan-out ⭐⭐⭐⭐⭐
This is the key interview answer.
Don't choose blindly between write and read fan-out.
Use a hybrid approach.
Normal users
Use:
Fan-out on write
Celebrity / high-follower users
Use:
Fan-out on read
17. Why Celebrity Users Are Special?
Suppose a celebrity has:
50 million followersThey post one tweet.
Fan-out on write means:
1 tweet
×
50M followers
=
50M feed writesOne tweet can suddenly generate 50 million writes.
That's a huge hotspot.
Instead:
Celebrity tweet
↓
Tweet Store
↓
Don't write to 50M feedsWhen followers load their timeline:
Normal Feed
+
Celebrity Tweets
↓
Merge + Rank
↓
Final TimelineThis is one of the most frequently discussed Twitter system-design concepts.
18. Hybrid Architecture
Tweet
│
┌─────────┴─────────┐
│ │
Normal User Celebrity
│ │
▼ ▼
Fan-out on Write Tweet Store
│ │
▼ │
Feed Storage │
│ │
└─────────┬─────────┘
▼
Feed Service
│
Merge + Ranking
│
▼
User⭐ Memorize:
Normal users → push tweets into feeds. Celebrities → pull tweets during feed generation.
19. Feed Cache
Home timelines are read frequently.
Use Redis-like caching.
User
↓
Feed Service
↓
Redis
↓
TimelineExample:
user123
↓
Feed Cache
↓
[T101, T205, T311, T400]This avoids repeatedly calculating the entire feed.
20. Why Not Store the Entire Feed Permanently?
Because feeds constantly change.
Suppose user follows:
5,000 usersThose users continuously publish tweets.
Instead, maintain a recent timeline window.
For example:
Recent 500 / 1,000 tweet IDsOlder tweets can be fetched when the user scrolls.
21. Tweet Storage
Tweet data can look conceptually like:
Tweet
------
tweet_id
author_id
text
created_at
media_idThe tweet itself is immutable after creation in many designs.
This makes it easier to:
Cache
Replicate
Distribute
22. Follow Graph
We need to store relationships:
Follower → FollowingExample:
Ramesh → A
Ramesh → B
Ramesh → CAnd potentially reverse:
A → Followers
B → Followers
C → FollowersWhy maintain both directions?
Because different operations need different access patterns.
Who does Ramesh follow?
Ramesh → following listWho follows A?
A → followers listThis can be modeled as separate adjacency lists/indexes.
23. Follow Graph Architecture
Follow Service
│
┌───────┴────────┐
▼ ▼
Following Store Followers Store
│ │
▼ ▼
User A → B User B → AAt huge scale, this graph needs careful partitioning.
24. Message Queue / Kafka ⭐
When a tweet is posted:
Tweet Service
│
▼
Kafka
│
├── Fan-out Workers
├── Notification
├── Analytics
├── Moderation
└── RecommendationWhy?
Because these tasks don't all need to happen synchronously.
25. Tweet Posting Flow
Suppose A posts:
"Hello World"
Step 1
A
↓
Tweet APIStep 2
Validate:
Authentication
Tweet length
Content
Rate limit
Step 3
Persist:
Tweet DBStep 4
Publish event:
TweetCreated
↓
KafkaStep 5
Consumers process:
Fan-out
Notification
Analytics
Moderation26. Timeline Read Flow
User opens Twitter.
User
↓
Feed Service
↓
Feed CacheIf cached:
Cache Hit
↓
Retrieve tweet IDs
↓
Fetch tweet objects
↓
Rank / hydrate
↓
ReturnFor celebrity tweets:
Feed
+
Celebrity tweets
↓
Merge
↓
Rank
↓
Return27. Ranking ⭐⭐⭐
Modern Twitter-style systems don't simply show:
newest tweets first.
A ranking service can consider:
Recency
User engagement
Author relationship
Likes
Replies
Reposts
Content relevance
User interests
Conceptually:
Candidate Tweets
↓
Ranking Service
↓
Score
↓
Top N tweets
↓
UserFor a basic system-design interview, start with chronological ordering, then mention ranking as an extension.
28. Media Architecture
Don't put videos directly into the Tweet DB.
Client
↓
Media Upload Service
↓
Object Storage
↓
CDNTweet:
tweet_id
media_referenceThe CDN handles delivery of popular media.
29. Database Choices
A possible design:
| Data | Storage |
|---|---|
| User | Relational / NoSQL |
| Tweets | Distributed NoSQL |
| Follow graph | NoSQL / graph-oriented access pattern |
| Feed | Redis + durable store |
| Media | Object Storage |
| Search | Elasticsearch/OpenSearch |
| Events | Kafka |
Don't focus too heavily on naming specific technologies.
The important thing is:
Choose storage based on access patterns.
30. Database Partitioning
Tweet queries commonly look like:
Give me tweets from user X
ordered by timeTherefore:
Partition key = author_id
Sort key = timestampcan be a reasonable starting point.
But celebrity accounts create hotspots.
So partitioning may need:
author_id + time_bucketor another carefully designed scheme.
31. Hot Partition ⭐
Suppose:
Celebrity X
50M followersand millions of users request that celebrity's tweets.
One partition can become overloaded.
Solutions:
Sharding
Time buckets
Replication
Caching
CDN where applicable
Celebrity-specific read strategy
32. Caching Strategy
Cache:
Feed
user → recent tweet IDsTweet
tweet_id → tweet objectUser profile
user_id → profilePopular content
Hot tweets can be heavily cached.
33. Consistency Model
Twitter can use:
Eventual consistency
Example:
Tweet created
↓
Some feeds update immediately
↓
Others update shortly afterwardThis is generally acceptable.
But:
Tweet permanently lostis not acceptable.
So distinguish:
Eventual consistency ≠ unreliable storage.
34. Peak Traffic
Suppose a major event occurs:
World Cup Final
↓
Millions of users open Twitter
↓
Timeline reads explodeNeed:
CDN
Caching
Horizontal scaling
Read replicas
Feed caches
Rate limiting
Queues
Autoscaling35. Reliability
If a feed worker crashes:
Kafka
↓
Retry
↓
Another workerUse:
Retries
Idempotent consumers
Dead-letter queues
Replication
Monitoring
36. Idempotency in Fan-out
Suppose:
Tweet T1
↓
Fan-out Worker
↓
Crash
↓
RetryWithout idempotency:
Feed A:
T1
T1 ❌Use:
user_id + tweet_idas an idempotency/deduplication key.
Then:
T1 already exists
→ Don't insert again37. Twitter vs WhatsApp — ⭐ Important Comparison
You have now covered both systems.
| Concept | ||
|---|---|---|
| Primary purpose | Messaging | Social broadcasting |
| Workload | Read-heavy | Read-heavy |
| Real-time | ⭐⭐⭐ | Important but less central |
| Connection | WebSocket | HTTP/API + feed services |
| Main challenge | Message delivery | Fan-out/feed generation |
| Consistency | More important | Availability more important |
| Group handling | Fan-out | Follower fan-out |
| Main storage | Messages | Tweets + feeds |
| Kafka | Events | Fan-out/events |
| Redis | Presence/connection | Feed/cache |
| CDN | Media | Media |
| Key deep dive | Ordering/offline | Fan-out/feed |
🎯 38. 30-Second Interview Answer
If the interviewer asks:
"Design Twitter."
Say:
"I would design Twitter as a distributed, read-heavy social network where availability and low latency are more important than strict global consistency. Users can follow each other, post tweets, and retrieve a personalized home timeline. I'd separate Tweet, User, Follow Graph and Feed services. Tweets would be durably stored and events published through Kafka. For normal users, I'd use fan-out-on-write to pre-populate follower feeds, giving very fast timeline reads. For celebrity users with millions of followers, fan-out-on-write would create a huge write amplification problem, so I'd use fan-out-on-read and merge celebrity tweets into the user's feed during read time. Redis can cache recent feed IDs and popular tweets, while object storage and CDN handle photos and videos. Horizontal scaling, replication, caching and asynchronous processing would allow the system to survive large traffic spikes."
🧠 39. Twitter — What You MUST Remember
TWITTER
│
┌────────────┼────────────┐
▼ ▼ ▼
Follow Tweet Timeline
│ │ │
│ ▼ │
│ Kafka │
│ │ │
│ Fan-out Workers │
│ │ │
│ ▼ │
│ Feed Storage │
│ │ │
└────────────┼────────────┘
▼
Feed Service
│
Merge + Rank
│
▼
User🔥 The golden interview concept
Twitter is fundamentally a fan-out problem.
And the best answer is:
Fan-out on write for normal users + fan-out on read for celebrities + hybrid feed generation.
One-line memory trick
Twitter = Follow Graph + Tweets + Fan-out + Feed Cache + Ranking + Celebrity Handling
📚 Your System Design Learning Map So Far
You now have a useful pattern across the systems you've studied:
Spotify
↓
Streaming + CDN + Object Storage
Amazon
↓
Catalog + Inventory + Payment + Checkout
WhatsApp
↓
WebSocket + Ordering + Offline Sync + Messaging
Twitter
↓
Follow Graph + Fan-out + Feed + RankingInterview tip: Don't memorize the architecture diagram alone. Memorize the one hard problem each system is testing:
| System | ⭐ Core Problem |
|---|---|
| Spotify | Smooth audio streaming at scale |
| Amazon | Inventory + payment consistency |
| Reliable ordered real-time messaging | |
| Massive feed fan-out |
