Twitter System Design - Follow Graph + Fan-out + Feed + Ranking

 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 tweets

Therefore:

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 experience

Therefore:

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────→ Elon

It does NOT automatically mean:

Elon ─────follows────→ Ramesh

This is an important distinction from a friendship model.

---

6. Post Tweet

Users can create tweets.

Example:

User
 ↓
Tweet Service
 ↓
Tweet DB

Tweet can contain:

• Text

• Photos

• Videos

---

7. Home Timeline ⭐⭐⭐

This is the most important feature.

If Ramesh follows:

A
B
C
D

his home timeline should contain tweets from:

A + B + C + D

ordered/ranked appropriately.

        Following
       /    |    \
      A     B     C
       \    |    /
        \   |   /
         Home Feed
             ↓
           Ramesh

---

8. User Timeline

A user should be able to see all/relevant tweets posted by a particular user.

Example:

twitter.com/userA
        ↓
User A's tweets

This 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
 ↓
CDN

Tweet stores a reference:

tweet_id
media_id
media_type

---

10. Non-Functional Requirements

① Availability ⭐⭐⭐

Twitter should remain available even if some servers fail.

---

② Low Latency

Timeline should load quickly.

User opens Twitter
       ↓
Timeline
       ↓
Fast response

A 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 requests

Examples:

• 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 followers

A celebrity might have:

50M followers

These two cases require different strategies.

---

Peak traffic

What happens during global events?

---

Read/write ratio

Likely:

Reads >>> Writes

---

Replication

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
                      │
                      ▼
                     CDN

---

13. The Most Important Concept — Fan-out ⭐⭐⭐⭐⭐

Suppose:

Ramesh
  ↓
posts tweet

Ramesh has:

1,000 followers

We 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 C

---

14. Fan-out on Write

When the tweet is created:

User posts tweet
       ↓
Tweet Service
       ↓
Find followers
       ↓
Write tweet into follower feeds

Example:

Ramesh posts T1

Followers:
A B C D E

Feed A ← T1
Feed B ← T1
Feed C ← T1
Feed D ← T1
Feed E ← T1

Then when users open Twitter:

User
 ↓
Feed Cache
 ↓
Already prepared timeline

Advantage

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 feed

Example:

User follows:

A → tweets
B → tweets
C → tweets
D → tweets

          ↓
       Merge
          ↓
       Ranking
          ↓
      Home Feed

Advantage

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 followers

They post one tweet.

Fan-out on write means:

1 tweet
 ×
50M followers
 =
50M feed writes

One tweet can suddenly generate 50 million writes.

That's a huge hotspot.

Instead:

Celebrity tweet
      ↓
Tweet Store
      ↓
Don't write to 50M feeds

When followers load their timeline:

Normal Feed
     +
Celebrity Tweets
     ↓
Merge + Rank
     ↓
Final Timeline

This 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
 ↓
Timeline

Example:

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 users

Those users continuously publish tweets.

Instead, maintain a recent timeline window.

For example:

Recent 500 / 1,000 tweet IDs

Older 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_id

The 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 → Following

Example:

Ramesh → A
Ramesh → B
Ramesh → C

And potentially reverse:

A → Followers
B → Followers
C → Followers

Why maintain both directions?

Because different operations need different access patterns.

Who does Ramesh follow?

Ramesh → following list

Who follows A?

A → followers list

This can be modeled as separate adjacency lists/indexes.

---

23. Follow Graph Architecture

                Follow Service
                     │
             ┌───────┴────────┐
             ▼                ▼
      Following Store    Followers Store
             │                │
             ▼                ▼
         User A → B        User B → A

At 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
      └── Recommendation

Why?

Because these tasks don't all need to happen synchronously.

---

25. Tweet Posting Flow

Suppose A posts:

"Hello World"

Step 1

A
 ↓
Tweet API

Step 2

Validate:

• Authentication

• Tweet length

• Content

• Rate limit

Step 3

Persist:

Tweet DB

Step 4

Publish event:

TweetCreated
 ↓
Kafka

Step 5

Consumers process:

Fan-out
Notification
Analytics
Moderation

---

26. Timeline Read Flow

User opens Twitter.

User
 ↓
Feed Service
 ↓
Feed Cache

If cached:

Cache Hit
 ↓
Retrieve tweet IDs
 ↓
Fetch tweet objects
 ↓
Rank / hydrate
 ↓
Return

For celebrity tweets:

Feed
 +
Celebrity tweets
 ↓
Merge
 ↓
Rank
 ↓
Return

---

27. 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
       ↓
User

For 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
 ↓
CDN

Tweet:

tweet_id
media_reference

The 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 time

Therefore:

Partition key = author_id
Sort key = timestamp

can be a reasonable starting point.

But celebrity accounts create hotspots.

So partitioning may need:

author_id + time_bucket

or another carefully designed scheme.

---

31. Hot Partition ⭐

Suppose:

Celebrity X
50M followers

and 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 IDs

Tweet

tweet_id → tweet object

User profile

user_id → profile

Popular 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 afterward

This is generally acceptable.

But:

Tweet permanently lost

is 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 explode

Need:

CDN
Caching
Horizontal scaling
Read replicas
Feed caches
Rate limiting
Queues
Autoscaling

---

35. Reliability

If a feed worker crashes:

Kafka
 ↓
Retry
 ↓
Another worker

Use:

• Retries

• Idempotent consumers

• Dead-letter queues

• Replication

• Monitoring

---

36. Idempotency in Fan-out

Suppose:

Tweet T1
 ↓
Fan-out Worker
 ↓
Crash
 ↓
Retry

Without idempotency:

Feed A:
T1
T1 ❌

Use:

user_id + tweet_id

as an idempotency/deduplication key.

Then:

T1 already exists
→ Don't insert again

---

37. Twitter vs WhatsApp — ⭐ Important Comparison

You have now covered both systems.

Concept	WhatsApp	Twitter
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 + Ranking

Interview 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
WhatsApp	Reliable ordered real-time messaging
Twitter	Massive feed fan-out