Design WhatsApp

Design WhatsApp — the 45-minute interview walkthrough

This lesson is the interview version of a chat system design: what to ask, what to draw, which deep dives to expect. The full reference design is the case study Design WhatsApp in this chapter.

A messaging system has one job that sounds simple: get a message from one phone to another fast, in order, exactly as sent, even if the recipient is offline for a week. The difficulty is doing it for billions of users over unreliable mobile networks, with delivery and read receipts, and with servers that can't read the content (end-to-end encryption).

Minutes 0–5: clarify requirements

• 1:1 and group chat? Group size limit? (A few hundred to ~1,000 members changes the fan-out strategy.)
• Receipts? Sent (✓), delivered (✓✓), read (blue ✓✓).
• Media? Images and video go through a separate upload path.
• Online presence and "typing…"? Nice to have, and expensive at scale.
• History? Stored on the server until delivered, or kept indefinitely? (WhatsApp's model: the server is a relay and stores messages only until they're delivered.)
• Scale: ~2 billion users, ~100 billion messages/day (~1.2 million/s average), and hundreds of millions of concurrent connections.

Say which properties matter most: low latency, no message loss, per-conversation ordering, and privacy.

Minutes 5–15: the high-level design

 Phone A ══ persistent connection ══▶ Gateway / Chat server 1 ─┐
                                                              │  "who holds B's connection?"
                                                  Session registry (userId → server)
                                                              │
 Phone B ◀══ persistent connection ══ Gateway / Chat server 2 ◀┘
                                              │
                        Message store (per-conversation, append-only, until delivered/acked)
                                              │
                        Push service (APNs/FCM) for offline recipients

1. Each phone keeps one long-lived connection (WebSocket or a custom TCP protocol) to a chat server. HTTP polling would mean billions of mostly empty requests and seconds of latency.
2. A session registry maps userId → which server holds their connection, stored in a fast replicated key-value store.
3. When A sends to B: A's server persists the message first, acks A (✓ sent), looks up B's server, and forwards it.
4. If B is online, B's server pushes it down the connection. B's phone acks, and a delivered receipt flows back to A (✓✓).
5. If B is offline, the message waits in B's pending queue, and a push notification wakes the app. On reconnect, B's phone fetches everything pending.

Minutes 15–35: the deep dives

1. Delivery guarantees and ordering

• Persist before ack. A's ✓ means "the server has it durably", so a server crash can't lose it.
• Client-generated message IDs make retries safe: if A's phone resends after a timeout, the server sees the same ID and doesn't store a duplicate. The recipient dedupes by ID too.
• Ordering per conversation: assign each message a sequence number per conversation, or a time-ordered ID. The recipient displays by that order and can detect gaps ("I have 41 and 43, fetch 42"). Global ordering across all conversations is unnecessary and would be a bottleneck.

2. Storage

The write pattern is massive, append-only, and read "latest first per conversation". A wide-column store (Cassandra-style) fits: partition key = conversation ID, clustering key = message sequence/time. Writes are cheap appends, and reading recent history is one partition scan. With the relay model, messages are deleted after all recipients ack, which keeps storage bounded.

3. Group messages: fan-out

For a group of N members, the server stores the message once and fans out delivery to each member's connection or pending queue. With groups capped at a few hundred, fan-out on write is fine. That's also why group sizes are capped. For huge broadcast channels you'd switch to fan-out on read (members pull from the channel's log).

4. Presence

"Online / last seen" is updated by heartbeats: the connection itself, or a ping every ~30 s. A user is considered offline after missing a few. Broadcasting every status change to every contact is enormously chatty, so presence is sent only to users currently viewing that chat, and updates are batched. It's acceptable for presence to be slightly stale.

5. End-to-end encryption

With the Signal protocol, each device has key pairs, and senders encrypt with keys only the recipient's devices hold. The server stores and forwards ciphertext it cannot read. Design consequences: the server can't search or moderate content, and multi-device support means encrypting per device. Mention it as a constraint the architecture must respect, not something to design cryptographically in the interview.

6. Media

Images and videos don't travel through the chat pipeline. The sender uploads the (encrypted) file to blob storage behind a CDN and sends a small message containing the reference and the key. That keeps chat servers handling only small messages.

Minutes 35–45: trade-offs and wrap-up

• Persistent connections give real-time delivery, but each server must handle hundreds of thousands of mostly idle connections. That's an event-driven, memory-efficient server design. Reconnect storms after a server dies need jittered backoff on clients.
• Relay model (delete after delivery) keeps storage small and supports privacy, at the cost of no server-side history. Cloud backup is a separate, client-driven feature.
• Per-conversation ordering instead of global ordering keeps the system horizontally scalable.

Common mistakes in interviews

• HTTP polling for new messages.
• Acking the sender before persisting.
• Designing global message ordering or a single central message table.
• Forgetting the offline recipient path (pending queue + push notification + fetch on reconnect).

Follow-up questions this topic invites — and their answers

Q: A chat server with 500,000 connections crashes. What happens? A: Those clients detect the dropped connection and reconnect, with jittered exponential backoff so they don't stampede, through the load balancer to other servers. The session registry updates to their new servers. No messages are lost, because messages are persisted before being acked, and anything not yet delivered is still in pending queues and is fetched on reconnect.

Q: How do read receipts work in a group? A: Each member's client sends a small read acknowledgement for the latest message it displayed. The server tracks the highest-read sequence per member and aggregates it for the sender ("read by 12 of 40"). Receipts are batched and low priority, because they're far more numerous than messages.

Q: How do you support the same account on a phone and a laptop? A: Treat each device as a separate endpoint with its own connection and keys. A message to a user is delivered, and encrypted, once per device, and each device acks independently. The session registry maps a user to several connections.

Q: How would you estimate the number of chat servers? A: Start from concurrent connections. Say 500 million concurrently online, and a well-tuned server holding ~500k idle connections: that's on the order of 1,000 servers, plus headroom for failover and peaks. Then check message throughput (~1–2 million/s spread across them) as a second constraint.