System Design Interview: Design WhatsApp

"Design WhatsApp" tests real-time delivery at massive scale, durable message storage, presence (online/last-seen), and the connection-management problem of keeping hundreds of millions of devices live. As always, the interviewer wants your reasoning and trade-offs, not a copy of the real system.

Move through it methodically: clarify requirements, estimate scale, design the connection and delivery path, decide how messages are stored, then handle group chat and the hard edges like offline delivery and ordering. The walk-through below follows that path.

1. Clarify requirements

Pin down scope first. The core is one-to-one messaging with reliable delivery; clarify whether group chat, media, and end-to-end encryption are in scope for this round.

• Functional: send/receive messages, delivery + read receipts, online presence, group chat, offline delivery when a recipient is disconnected.
• Non-functional: low latency, high availability, durability (no lost messages), ordering within a conversation.
• Clarify: E2E encryption and media handling — acknowledge them, scope in or out explicitly.

2. Estimate scale

Set the numbers that drive design. Assume ~2B users and tens of billions of messages per day; that's hundreds of thousands of messages per second at peak, and hundreds of millions of simultaneously-connected devices — connection management becomes a first-class problem.

3. Connection and delivery path

Messaging needs a persistent connection, not request/response polling. Devices hold an open WebSocket to a gateway server. A central component must know which gateway currently holds each user's connection so a message can be routed to the right server.

• WebSocket gateway: maintains live device connections, handles send/receive.
• Session/presence registry: maps user → current gateway server (e.g. in Redis), updated on connect/disconnect.
• Message routing: sender's gateway looks up the recipient's gateway and forwards; if offline, the message is queued.

4. Message storage and offline delivery

Messages must survive a disconnected recipient. Persist each message durably and track per-recipient delivery state; deliver immediately if the recipient is online, otherwise store-and-forward when they reconnect.

A write-heavy, key-by-conversation access pattern favors a wide-column store like Cassandra (high write throughput, horizontal scale) over a single relational DB. Once a message is confirmed delivered to all recipients, it can be deleted or aged out, since WhatsApp doesn't retain delivered messages server-side indefinitely.

5. Group chat

Group messaging is fan-out: one send becomes N deliveries. For typical group sizes, fan-out-on-write (push to each member's delivery path) is simple and fast to read. Note the trade-off — very large groups make fan-out-on-write expensive, which is why huge broadcast groups are a different design problem.

6. Trade-offs to verbalize

Finish on the tensions: ordering (per-conversation sequence numbers vs global ordering), consistency vs availability for receipts (eventual is fine for 'last seen', stronger for delivery), and fan-out-on-write vs on-read for groups. Calling these out is what makes the answer senior.

Practice WhatsApp system design with real-time help

Natively's system design interview assistant can keep you structured during a live round — suggesting the next dimension to cover and surfacing trade-offs in real time, all on your own device.

• System Design Interview Assistant
• System Design: Uber
• System Design: Netflix
• System Design: Twitter