Whatsup System Design -

 WhatsApp System Design

        │
        ├── WebSocket
        ├── Connection Registry
        ├── Message Ordering
        ├── Persistent Message Store
        ├── Offline Delivery
        ├── Group Fan-out
        ├── Idempotency
        └── Presence / Typing

💬 WhatsApp System Design — Interview Class Notes

This is a real-time messaging system, so the architecture is quite different from Spotify and Amazon.

The key challenge is:

Deliver messages to the right users, in the right order, with very low latency, even when users are online on multiple devices or temporarily offline.

---

1. Problem Statement

Design a WhatsApp-like messaging platform supporting:

• 1-to-1 chat

• Group chat

• Persistent chat history

• Text messages

• Images/videos/voice

• Online/last-seen status

• Typing indicator

• Push notifications

• Offline message delivery

• Multiple devices

---

2. Three Core Assumptions ⭐

① Read-heavy or Write-heavy?

Slightly read-heavy

At first glance, messaging appears balanced:

SEND message → WRITE
RECEIVE/read message → READ

But in reality, many users read messages without responding.

Group chats make this even more read-heavy:

1 person sends
      ↓
50 people read

Therefore:

WhatsApp is generally read-heavy, although the read/write ratio is much closer than an e-commerce system.

---

3. Distributed or Single Server?

Distributed system

A single server cannot handle:

• Billions of messages

• Millions of concurrent connections

• Global users

• Media

• Group chats

• Offline users

Architecture needs:

Users
  ↓
Load Balancer
  ↓
Messaging Servers
  ↓
Distributed Storage

---

4. Consistency or Availability?

Consistency is particularly important

The transcript correctly emphasizes message ordering and consistency.

Consider:

A: "Are you coming?"
B: "Yes"
C: "Where?"

If another device receives:

B
C
A

the conversation becomes confusing.

We therefore need:

• Message ordering

• No accidental duplication

• Reliable delivery

• Consistent chat history

However, don't say WhatsApp requires strong consistency everywhere.

A better interview answer is:

Message ordering and durable message state require strong correctness guarantees, while presence, typing indicators and some notification paths can favor availability and eventual consistency.

---

5. Functional Requirements

Core Requirements

1. 1-to-1 Chat

Users can send messages to contacts.

User A
  │
  │ "Hello"
  ▼
WhatsApp
  │
  ▼
User B

---

2. Group Chat

Users can:

• Create groups

• Join groups

• Leave groups

• Add/remove members

• Send messages

Example:

             Group
               │
       ┌───────┼────────┐
       ▼       ▼        ▼
      A        B        C
       \       │       /
        \      │      /
         └── Messages

---

6. Supporting Features

3. Push Notifications

If recipient is offline:

Sender
  ↓
Messaging Service
  ↓
Message Store
  ↓
Push Notification Service
  ↓
APNs / FCM
  ↓
Recipient Phone

Important:

Push notification is not the message itself.

The notification tells the device that a message is available.

---

4. Chat History

Messages should be persistent.

Conversation
     │
     ├── Message 1
     ├── Message 2
     ├── Message 3
     └── Message 4

When user opens WhatsApp later:

Client
  ↓
Message Service
  ↓
Message DB
  ↓
Chat history

---

5. Rich Messages

Messages can contain:

• Text

• Images

• Videos

• Voice messages

• Documents

• Location

Don't store large media directly inside the message database.

Instead:

Media
  ↓
Object Storage
  ↓
CDN

Message database stores:

message_id
conversation_id
sender_id
timestamp
message_type
media_reference

---

7. Online / Last Seen

Users should see:

Online
Last seen 10:32 AM

This is a presence system.

Presence changes frequently:

ONLINE
  ↓
OFFLINE
  ↓
ONLINE
  ↓
OFFLINE

Don't write every presence update heavily into a durable database.

Use a fast distributed cache such as Redis and/or an in-memory presence layer.

User
 ↓
Presence Service
 ↓
Redis

---

8. Typing Indicator

Example:

Ramesh is typing...

Typing is ephemeral information.

It does not need permanent storage.

User A
   │
   │ typing
   ▼
WebSocket
   │
   ▼
User B

Don't store:

"Ramesh started typing at 11:02:31"

in your main database.

Instead send a lightweight real-time event.

---

9. Non-Functional Requirements ⭐⭐⭐

① Very Low Latency

Messaging should feel real-time.

Target:

Send
 ↓
Server
 ↓
Recipient

should normally happen in milliseconds to low hundreds of milliseconds depending on network conditions.

---

② High Consistency

Important for:

• Message ordering

• Message delivery state

• Chat history

• Multi-device synchronization

---

③ High Availability

WhatsApp should work even when individual servers fail.

Use:

• Replication

• Multiple messaging servers

• Multi-region architecture

• Automatic failover

---

④ Reliability

Messages shouldn't disappear because one server crashed.

Need:

• Durable storage

• Replication

• Acknowledgements

• Retries

• Idempotency

---

⑤ Scalability

Millions of concurrent users may maintain long-lived connections.

This is a major difference from Amazon.

---

10. Scope Questions

Before designing, ask:

Users

How many DAUs?

Messages

How many messages are sent per user per day?

Message size

What is the average text message size?

Read/write ratio

How many reads per message write?

Peak traffic

What happens during Friday evening or festivals?

History

How long should messages be retained?

Replication

What's the database replication factor?

Group size

A very useful additional question:

What is the maximum/average group size?

Because a group with 10 members is very different from a group with 100,000 members.

---

11. High-Level Architecture ⭐⭐⭐

This is the first architecture I would draw.

                         USERS
                           │
                           ▼
                    ┌─────────────┐
                    │ Load Balancer│
                    └──────┬──────┘
                           │
                ┌──────────┼──────────┐
                ▼          ▼          ▼
             Chat       Chat        Chat
             Server     Server      Server
                │          │          │
                └──────────┼──────────┘
                           │
                    Message Service
                           │
              ┌────────────┼────────────┐
              ▼            ▼            ▼
         Message DB     Redis       Kafka
              │                         │
              │                 ┌───────┼────────┐
              │                 ▼       ▼        ▼
              │             Notification Analytics
              │               Service
              │                 │
              │             APNs/FCM
              │                 │
              ▼                 ▼
          Chat History       Offline User

For media:

User
 ↓
Media Service
 ↓
Object Storage
 ↓
CDN
 ↓
Recipient

---

12. Persistent Connection — ⭐⭐⭐ Important

This is one of the biggest concepts to remember.

Traditional HTTP:

Client
  ↓ HTTP Request
Server
  ↓ Response
Connection ends

That isn't ideal for real-time messaging.

Instead use:

WebSocket / persistent connection

User A
   │
   │ Persistent connection
   ▼
Chat Server
   │
   │ Persistent connection
   ▼
User B

The server can push messages immediately.

---

13. Why WebSocket?

Suppose User B sends a message.

With polling:

Client → Any new message?
Server → No

Client → Any new message?
Server → No

Client → Any new message?
Server → YES

Wasteful.

With WebSocket:

User B
  │
  │ Message
  ▼
Server
  │
  │ Push immediately
  ▼
User A

Much better for real-time communication.

---

14. Connection Routing Problem ⭐⭐⭐

Suppose:

User A → Chat Server 1
User B → Chat Server 7

How does Server 1 find User B?

We need a distributed mapping:

User ID
   ↓
Connection Registry
   ↓
User B → Chat Server 7

For example:

Redis

userA → server1
userB → server7
userC → server3

Then:

Server 1
   ↓
Lookup User B
   ↓
Server 7
   ↓
WebSocket
   ↓
User B

This is a very important interview deep dive.

---

15. Message Flow — 1-to-1 Chat

Suppose A sends:

Hello B

Step 1

A sends through WebSocket:

A
 ↓
Chat Server

Step 2

Server validates:

• Authentication

• Authorization

• Conversation membership

• Message format

Step 3

Generate:

message_id
timestamp
conversation_id

Step 4

Persist message:

Message DB

Step 5

Find B's connection:

Connection Registry
 ↓
B → Chat Server 7

Step 6

Forward message:

Chat Server 1
       ↓
Chat Server 7
       ↓
User B

Step 7

Return acknowledgement to A.

A
 ↓
Server
 ↓
ACK

---

16. Message Delivery States

A useful design:

SENT
  ↓
SERVER_ACK
  ↓
DELIVERED
  ↓
READ

For example:

✓       Sent
✓✓      Delivered
✓✓ blue Read

Internally, you can model:

SENT
DELIVERED
READ

---

17. Message Ordering ⭐⭐⭐

This is one of the most important WhatsApp interview topics.

Suppose:

M1 = "Hello"
M2 = "How are you?"
M3 = "Are you free?"

Recipient must see:

M1
M2
M3

not:

M2
M1
M3

Solution

Assign ordering information.

For example:

conversation_id
sequence_number

Conversation 123

M1 → seq 101
M2 → seq 102
M3 → seq 103

The receiver can use sequence numbers to detect:

101
103

and understand that:

102 is missing

---

18. Important Nuance: Don't Use One Global Sequence

A common interview mistake is saying:

"We'll have one global sequence number for all WhatsApp messages."

Bad idea.

With billions of messages, a global ordering mechanism becomes a bottleneck.

Instead:

Partition ordering by conversation/chat.

Conversation A
  1 → 2 → 3 → 4

Conversation B
  1 → 2 → 3

This scales much better.

---

19. Group Message Flow

Suppose:

Group = A, B, C, D, E

A sends:

Hello everyone

Architecture:

A
 ↓
Chat Server
 ↓
Message Store
 ↓
Group Membership
 ↓
B C D E

The system needs to deliver to each member.

---

20. Small Group vs Huge Group

For a small group:

Message
 ↓
Fan-out to members

works well.

But imagine:

1 message
×
100,000 members

That's expensive.

For huge groups, consider:

• Topic/partition-based fan-out

• Pull-based delivery

• Hybrid fan-out

• Asynchronous workers

This is a strong scaling discussion.

---

21. Fan-out on Write vs Fan-out on Read

Fan-out on Write

When A sends:

A → Group

immediately create/deliver copies for members.

Good for:

Small groups

---

Fan-out on Read

Store one message:

Message Store

Members fetch messages when needed.

Good for:

Very large groups

---

Hybrid

Use:

Small groups → Fan-out on write
Large groups → Fan-out on read

Excellent interview answer.

---

22. Offline User Flow ⭐⭐⭐

Suppose B is offline.

A
 ↓
Message Server
 ↓
Message DB
 ↓
B offline

Message remains stored.

When B reconnects:

B
 ↓
Chat Server
 ↓
Get messages after last acknowledged sequence
 ↓
Message DB
 ↓
M1 M2 M3

Then send them to B.

This is why persistent storage + client acknowledgement is essential.

---

23. Multi-Device Synchronization

Suppose B uses:

Phone
Laptop
Tablet

A message arrives.

All devices should eventually synchronize.

                 Message Service
                       │
             ┌─────────┼─────────┐
             ▼         ▼         ▼
           Phone     Laptop     Tablet

Use:

• Per-device connection

• Device-specific delivery state

• Sequence numbers

• Sync cursor / last acknowledged message

This is a good advanced interview topic.

---

24. Database Choice

Message volume is enormous.

A relational DB may not be ideal as the only storage layer.

A distributed NoSQL database such as:

• Cassandra-like architecture

• DynamoDB-like architecture

can work well for message history because access is commonly:

conversation_id
+
time range

Example:

Partition key:
conversation_id

Sort key:
message_timestamp / sequence

Conceptually:

Conversation 123
 ├── M1
 ├── M2
 ├── M3
 └── M4

---

25. Database Partitioning

Partition by:

conversation_id

or a carefully designed conversation/shard key.

Why?

Most queries are:

"Give me messages for this conversation."

So the partition key should align with the access pattern.

---

26. Redis

Redis can be useful for:

• User → connection mapping

• Online status

• Typing status

• Session information

• Short-lived metadata

• Rate limiting

But don't use Redis as the permanent source of truth for chat history.

---

27. Kafka

Kafka is useful for asynchronous events:

Message Event
     ↓
Kafka
     │
 ┌───┼───────────┐
 ▼   ▼           ▼
Push Analytics  Moderation

But don't automatically put every latency-sensitive message delivery step behind a slow asynchronous pipeline.

The real-time path should remain optimized.

---

28. Media Architecture

For image/video/audio:

User
 ↓
Media Upload Service
 ↓
Object Storage
 ↓
CDN
 ↓
Recipient

Message record contains:

message_id
media_id
media_type
storage_reference

rather than a huge binary blob.

---

29. Exactly Once vs At Least Once ⭐

Distributed systems can make exactly-once delivery difficult.

A practical design often uses:

At-least-once delivery + idempotency

Message
 ↓
Retry
 ↓
Message arrives twice

Client/server detects duplicate:

message_id = ABC123

If ABC123 already processed:

Ignore duplicate

Therefore:

Use unique message IDs and idempotent processing to achieve effectively-once user-visible behavior.

---

30. Failure Scenario

Suppose Chat Server crashes after storing the message but before sending the ACK.

Client retries.

Client
 ↓
Message ABC
 ↓
Server stores ABC
 💥
Connection lost
 ↓
Client retries ABC

If server doesn't use idempotency:

ABC
ABC

Duplicate message.

With message ID:

ABC → already exists

return existing result.

---

31. Availability vs Consistency by Feature

This table is extremely useful in interviews.

Feature	Priority
Message ordering	Consistency
Message persistence	Consistency
Message delivery state	Consistency
Chat history	Consistency
Presence	Availability / eventual consistency
Typing indicator	Availability
Push notification	Availability
Analytics	Eventual consistency
Read receipts	Reasonable consistency

---

32. CAP Theorem Answer

If interviewer asks:

"Why consistency over availability?"

Say:

"For messaging, correctness of the conversation is critical. Users should not see messages reordered, duplicated or disappear from chat history. Therefore message persistence, ordering and delivery state need strong correctness guarantees. However, ephemeral features such as typing indicators and presence can sacrifice consistency temporarily to remain highly available."

That's a much stronger answer than simply saying:

"WhatsApp chooses consistency."

---

33. Reliability

Use:

Replication
Failover
Retries
Idempotency
Acknowledgements
Dead-letter handling
Monitoring

Example:

Message DB
   │
   ├── Replica 1
   ├── Replica 2
   └── Replica 3

If one replica fails:

Other replicas continue serving.

---

34. Security

WhatsApp-like messaging should also consider:

• Authentication

• Authorization

• Encryption in transit

• Encryption at rest

• End-to-end encryption

• Key management

• Abuse prevention

• Rate limiting

E2E Encryption

Conceptually:

User A
  │
Encrypt
  │
  ▼
Server
  │
Encrypted message
  │
  ▼
User B
  │
Decrypt

The server transports/stores ciphertext rather than having access to plaintext where the E2E design requires it.

---

35. Observability

Monitor:

Messaging

• Messages/sec

• Delivery latency

• Failed deliveries

• Duplicate messages

Connections

• Active WebSocket connections

• Connections/server

• Connection failures

Database

• Read/write latency

• Replication lag

• Hot partitions

Kafka

• Consumer lag

Business

• Active users

• Messages/day

• Group activity

---

36. Back-of-the-Envelope Estimation

Suppose we assume:

DAU = 500M
Messages/user/day = 50

Then:

500M × 50
=
25 billion messages/day

Average messages/sec:

25B / 86,400
≈ 289,000 messages/sec

Peak traffic could easily be several times higher.

For example:

Peak ≈ 5× average

≈ 1.45M messages/sec

This immediately tells the interviewer:

We need a horizontally scalable distributed messaging architecture.

---

37. Concurrent Connections

Messaging is special because users may maintain long-lived connections.

Suppose:

300M concurrent connections

and one server safely supports:

100K connections

Then approximately:

300M / 100K
=
3,000 servers

This is why connection management itself becomes a major scaling problem.

---

38. Complete Architecture ⭐⭐⭐

                         USERS
                           │
                    WebSocket / HTTPS
                           │
                           ▼
                    Load Balancer
                           │
            ┌──────────────┼──────────────┐
            ▼              ▼              ▼
        Chat Server    Chat Server    Chat Server
            │              │              │
            └──────────────┼──────────────┘
                           │
                    Message Service
                           │
             ┌─────────────┼─────────────┐
             │             │             │
             ▼             ▼             ▼
        Message DB      Redis          Kafka
             │             │             │
             │             │       ┌─────┼──────┐
             │             │       ▼     ▼      ▼
             │             │    Push  Analytics Moderation
             │             │
             │       Connection /
             │       Presence Registry
             │
             ▼
         Chat History

              Media Messages
                    │
                    ▼
              Media Service
                    │
                    ▼
             Object Storage
                    │
                    ▼
                   CDN

---

🧠 39. WhatsApp Interview Flow

When interviewer says:

"Design WhatsApp."

Follow this sequence:

Step 1 — Clarify scale

Ask:

DAU?
Messages/day?
Peak messages/sec?
Average message size?
Retention?
Average/max group size?
Concurrent connections?
Replication?

Step 2 — Requirements

1-to-1 chat
Group chat
Offline messaging
Chat history
Notifications
Media
Presence
Typing indicator

Step 3 — NFR

Low latency
High reliability
High availability
Message ordering
Scalability

Step 4 — High-level architecture

Start:

Client
 ↓
Load Balancer
 ↓
Chat Servers
 ↓
Message Store

Then add:

Redis
Kafka
Object Storage
CDN
Push Notification

Step 5 — Deep dive ⭐

Focus on:

WebSocket → connection routing → message persistence → ordering → offline delivery

Step 6 — Group chat

Explain:

Fan-out on write vs fan-out on read

Step 7 — Failure handling

Explain:

Retries + message IDs + idempotency

---

🎯 40. 30-Second Interview Answer

"I would design WhatsApp as a distributed real-time messaging system using persistent WebSocket connections for low-latency communication. Users connect to horizontally scalable chat servers, while a distributed connection registry maps users to the servers holding their connections. Messages are assigned unique IDs and conversation-level sequence numbers, persisted in a replicated message store, and then delivered to the recipient or retained for offline synchronization. Redis can handle presence, connection metadata and other ephemeral state, while Kafka can process asynchronous events such as notifications and analytics. Media should go to object storage and be delivered through a CDN. For groups, I would use fan-out-on-write for small groups and a hybrid or fan-out-on-read approach for very large groups. Idempotency, acknowledgements and retries provide reliable delivery without duplicate user-visible messages."

⭐ The 8 concepts to memorize

WhatsApp System Design
        │
        ├── WebSocket
        ├── Connection Registry
        ├── Message Ordering
        ├── Persistent Message Store
        ├── Offline Delivery
        ├── Group Fan-out
        ├── Idempotency
        └── Presence / Typing

🔥 One-line memory trick

WhatsApp = WebSocket + Message Queue/Store + Ordering + Offline Sync + Group Fan-out + Presence

This is the core mental model you should carry into the interview.