Design WhatsApp

Problem Statement

Design WhatsApp as a fan-out system where freshness, delivery order, and hot users create the real scaling pressure. For Design WhatsApp, name the critical user action, the data that must remain correct, and the first bottleneck that appears when traffic grows.

Deep-Dive: Clarifying Questions for WhatsApp

1. What is the message volume? WhatsApp processes over 100 billion messages per day across 2 billion users. Average user sends about 50 messages/day.
2. Do we need end-to-end encryption? WhatsApp uses the Signal Protocol for E2E encryption. Messages are encrypted on the sender's device and can only be decrypted on the recipient's device. The server NEVER sees plaintext.
3. How do we handle offline delivery? If the recipient is offline, messages must be stored (encrypted) on the server and delivered when they reconnect. How long do we retain undelivered messages?
4. Do we need group messaging? Groups up to 1,024 members with shared encryption keys that rotate when members leave.
5. Do we need read receipts and typing indicators? Blue double-check marks, "typing..." indicators, and "last seen" status are real-time signals that require persistent connections.
6. What media types? Text, images (up to 16 MB), videos (up to 16 MB), voice messages, documents, location sharing, contacts.

Specific Functional Requirements

1. One-to-One Messaging: Send text, images, videos, voice notes, and documents to individual users with end-to-end encryption
2. Group Messaging: Create groups of up to 1,024 members with shared message history
3. Offline Message Delivery: Queue messages for offline users and deliver them when they reconnect, with message ordering preserved
4. Read Receipts: Show sent (single check), delivered (double check), and read (blue double check) status per message
5. Typing Indicators: Show real-time "typing..." status to the conversation partner
6. Media Upload/Download: Handle image, video, and document sharing with automatic compression and thumbnail generation
7. Last Seen and Online Status: Show when a user was last active on the platform

Specific API Design

WhatsApp uses a persistent WebSocket connection for real-time messaging, NOT HTTP polling.

WebSocket /ws/connect
  Auth: Bearer token (established on connection)

Client sends: { "type": "message", "to": "user_456", "id": "msg_abc", "content": { "type": "text", "body": "encrypted_base64..." } }
Server acknowledges: { "type": "ack", "id": "msg_abc", "status": "sent", "timestamp": 1234567890 }
Server delivers to recipient: { "type": "message", "from": "user_123", "id": "msg_abc", "content": {...} }
Recipient acknowledges: { "type": "ack", "id": "msg_abc", "status": "delivered" }
Recipient reads: { "type": "ack", "id": "msg_abc", "status": "read" }

Typing indicator: { "type": "typing", "to": "user_456", "status": "started" }

For media: upload encrypted media to blob storage via HTTP, then send the decryption key and media URL in the WebSocket message.

Specific Data Model

Message Store (Cassandra): Optimized for write-heavy, append-only workload. Messages are partitioned by (recipient_id, conversation_id) for efficient "get messages for conversation" queries.

Connection Registry (Redis): Maps online users to the WebSocket server they are connected to.

• Key: user_id, Value: { websocket_server_id, connected_at, last_heartbeat }
• When sending a message, look up the recipient's WebSocket server and route the message there

User Last Seen (Redis): Key = user_id, Value = timestamp of last activity. Updated on every message or heartbeat.

Specific Back-of-the-Envelope Numbers

Traffic:

• 2 billion users, 500M DAU
• 100 billion messages/day = ~1.15 million messages/second
• Each message triggers: 1 write (store), 1 read (deliver), 2-3 status updates = ~4M ops/second
• Concurrent WebSocket connections: 500M peak

Storage:

• Average text message: 100 bytes (encrypted) + 200 bytes metadata = 300 bytes
• 100B messages/day * 300 bytes = 30 TB/day for text messages
• Messages retained for 30 days (until delivered) or 90 days for group messages
• Media: 5B media messages/day * 500 KB average = 2.5 PB/day (stored in object storage with CDN)

Connection infrastructure:

• 500M concurrent WebSocket connections
• Each connection: ~10 KB memory overhead = 5 TB of RAM just for connections
• Need ~50,000 WebSocket servers (10K connections each)

Latency targets:

• Message delivery: under 200ms for online recipients
• Offline message delivery: within 5 seconds of reconnection
• Typing indicator: under 100ms end-to-end

Original DosiBridge notes for Design WhatsApp

This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Design WhatsApp is to connect the concept to a fan-out system where freshness, delivery order, and hot users create the real scaling pressure. That framing changes the design discussion from definitions to operating choices.

What makes this topic distinct

• Core Entity: For Design WhatsApp, decide the core entity before choosing tools; otherwise the design looks clean but fails when whatsapp changes.
• Read/Write Path: For Design WhatsApp, decide the read/write path before choosing tools; otherwise the design looks clean but fails when whatsapp changes.
• Contention Point: For Design WhatsApp, decide the contention point before choosing tools; otherwise the design looks clean but fails when whatsapp changes.
• Abuse Path: For Design WhatsApp, decide the abuse path before choosing tools; otherwise the design looks clean but fails when whatsapp changes.
• Recovery Workflow: For Design WhatsApp, decide the recovery workflow before choosing tools; otherwise the design looks clean but fails when whatsapp changes.

Design WhatsApp correctness boundary

For this problem, separate the user-visible action from background work. The correctness boundary is the smallest state transition that must not be duplicated, lost, or reordered. Naming that boundary makes the solution more original than a stock API/database/cache template.

Design WhatsApp scaling bottleneck

The first bottleneck should be described in the language of this system: a hot timeline, a contested seat, a busy wallet ledger, a media-processing queue, or a search index update delay. That bottleneck decides which component deserves the deepest interview discussion.

Production review question

If Design WhatsApp suddenly receives 10x traffic, which entity becomes contested first, and what queue, lock, shard, or cache protects that entity without hiding correctness bugs?

Practical metric to track

Track whatsapp health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Design WhatsApp, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.

Sources

• Design WhatsApp — Reference
• Source: System-Design-Overview