Design WhatsApp

You're asked to design WhatsApp: a messaging product for one-to-one and group conversations, with the constraint that messages are end-to-end encrypted. The operator cannot read message content, cannot hand it to anyone who asks, and cannot use it to build any server-side feature. Everything else the product does still has to work: delivery, groups, media, multiple devices, and history.

If you've already worked through Design Facebook Messenger, the delivery machinery here is the same. The interesting question is what changes once the server holds ciphertext, because encryption removes capabilities that most messaging designs quietly assume.

Clarifying the requirements

• Is end-to-end encryption required? Confirm it explicitly and confirm what it rules out, because the follow-ups will be about exactly that.
• How large are groups? Up to a few thousand in the modern product, which matters because naive group encryption cost grows with membership.
• Multi-device? Yes, and this is the genuinely hard part of encrypted messaging. Worth flagging as a deep dive candidate.
• Is history stored on the server? No, and that's the design's most consequential difference. The server holds messages only until delivery.
• What about backups? They exist, and their encryption is a separate decision from message encryption. Raising this shows you've thought past the happy path.

Assume: E2EE required, groups up to a few thousand, multi-device, no server-side history, optional encrypted backup.

Back-of-envelope numbers

• Users: $2\text{B monthly}$, roughly $1\text{B}$ connected at peak
• Connections: at $100\text{k}$ per gateway, $1\text{B} \div 100\text{k} = 10{,}000 \text{ gateways}$ plus headroom
• Messages: $100\text{B/day} \approx 1.2\text{M msg/sec}$, peaking several times higher
• Undelivered storage: messages are held only until delivery, so at roughly $1\%$ pending for $24\text{ hours}$, that's $1\text{B messages} \times 300\text{ B} \approx 300\text{ GB}$, three orders of magnitude below a history-storing design
• Key material: $2\text{B users} \times 100 \text{ prekeys} \times 32\text{ B} \approx 6\text{ TB}$, which is a real store in its own right

Those two storage figures are worth putting side by side in the interview. Not storing history turns petabytes into hundreds of gigabytes, and it's a direct consequence of the encryption requirement rather than a separate optimization.

High-level architecture

Components

1. Connection gateway. Holds the persistent socket; sees ciphertext only.
2. Message router. Routes by recipient identity, with no ability to inspect content.
3. Pending store. Ciphertext held until delivered, then deleted.
4. Key directory. Public identity keys and one-time prekeys, so a sender can encrypt to a recipient who is offline.
5. Push service. Wakes a device; the notification carries no readable content.
6. Recipient gateway. Delivers to the connected device.
7. Media store. Encrypted blobs, downloaded directly by the recipient with a key that travelled in the message.

Deep dive 1: what encryption takes away

Start here, because it frames every later decision and it's the part that distinguishes a considered answer from a generic messaging design.

With the server unable to read messages, these become impossible rather than merely unimplemented:

• Server-side search. History search must run on the device, over the local database, which is why search quality differs from products that index centrally.
• Server-side history and new-device sync. The server has nothing readable to hand a new device, so history transfer is a device-to-device or encrypted-backup problem.
• Content-based features. Spam classification, link previews generated server-side, smart replies, and content moderation on message bodies all lose their input.
• Rich push notifications. The push provider can't be given text, so the notification says a message arrived and the device decrypts and renders it locally.

What the server can still see is metadata: who talks to whom, when, how often, and how large the messages are. Saying this plainly is a mark of a candidate who understands the guarantee's actual boundary rather than repeating a marketing claim.

Two things the design keeps, and should say it keeps: abuse handling moves to metadata and user reports, since a rate of two thousand messages an hour to strangers is visible without reading any of them; and a reported message can be examined because the reporter's device supplies the plaintext they already hold.

Deep dive 2: keys, and encrypting to someone who is offline

The mechanism that makes this practical is worth explaining, because "we use the Signal protocol" without the shape underneath is a shallow answer.

Each device publishes to the key directory on registration:

• An identity key, long-lived, representing the device.
• A signed prekey, rotated periodically.
• A batch of one-time prekeys, consumed one per new conversation.

To message someone who is offline, the sender fetches a prekey bundle from the directory and derives a shared secret without the recipient ever being online. That asynchronous property is what makes encrypted messaging usable in a product where people are asleep. The server hands out prekeys and removes each as it's consumed, which is its entire role. It never holds a private key.

From there the session uses a double ratchet: keys advance with every message and with every round trip. The property that buys you is forward secrecy, meaning a key compromised today doesn't decrypt yesterday's messages, plus post-compromise recovery, where the session heals once a fresh exchange happens.

Two operational details are worth surfacing:

• Prekeys run out. A popular account can exhaust its batch, and the client must replenish. The fallback when the batch is empty is the signed prekey, which works but reuses key material, so replenishment needs monitoring.
• Key changes are visible to users. When a contact reinstalls, their identity key changes, and the product surfaces this. That notification is the defense against the server silently substituting a key it controls, which is otherwise the attack an end-to-end system is most exposed to.

Deep dive 3: encrypted groups without N-squared cost

Groups are where naive encryption gets expensive. A message to a thousand-person group encrypted separately per recipient means a thousand encryption operations and a thousand ciphertexts uploaded, per message, from a phone.

Sender keys fix the common case. Each member generates a sending key, distributes it once to every other member over the existing pairwise encrypted channels, and thereafter encrypts each message a single time. The server fans the one ciphertext out to all members. Cost per message drops from linear in group size to constant, and the expensive distribution happens once rather than per message.

The tradeoff is membership changes. When someone leaves, the sender key must be rotated and redistributed, or the departed member could still decrypt future traffic. That makes leaving a group an O(N) operation, and it's the right place to spend the cost, since it's rare and correctness-critical.

Two more points worth raising:

• The server still enforces membership for routing purposes, since it decides where the ciphertext goes. That's a metadata-level control, and it's compatible with not reading content.
• Large groups weaken the guarantee in practice. A thousand people can each screenshot and forward. The cryptography is intact; the human system around it isn't, and acknowledging that is more credible than claiming the property scales indefinitely.

Deep dive 4: multi-device and backup

This is the hardest problem in encrypted messaging, and the one where a candidate can most clearly show depth.

The naive approach is to treat the phone as the master and have companions proxy through it, which means the laptop stops working when the phone's battery dies. The modern approach is each device its own identity: every device has its own key pair and is a full participant, so a message to a user is encrypted separately to each of their devices.

That resolves availability and creates two new problems:

• History for a new device. The server has no readable copy, so history either transfers device-to-device over an authenticated channel, or comes from an encrypted backup. Either way it's a deliberate transfer, not a silent sync.
• Linking a device is a trust decision. Adding a device adds a key that can read future messages, which is why linking requires physical proof, such as scanning a QR code on the existing device, rather than a password. A password-only path would make account compromise equal message compromise.

Backups deserve their own answer. A cloud backup is where end-to-end encryption most often quietly fails, because an unencrypted backup hands the plaintext to a cloud provider and undoes the guarantee. The design that holds is a backup encrypted with a key the user controls, derived from a passphrase or stored in a hardware security module that enforces a limited number of retry attempts. And the honest caveat: a lost passphrase means unrecoverable history, which is a real product cost the design has to accept rather than engineer around.

Common pitfalls

• Claiming end-to-end encryption while designing server-side search or history. The two are incompatible, and the contradiction is what the interviewer is listening for.
• Encrypting per recipient in large groups. Cost per message grows with membership; sender keys make it constant.
• Ignoring key rotation on group membership changes. A departed member keeps reading.
• A phone-as-master multi-device model. The companion device dies with the phone's battery.
• Unencrypted cloud backups. The most common way this guarantee is lost in practice.

Leveling the answer

Related lessons

Design Facebook MessengerHard

Deliver messages across multiple devices with read receipts and server-stored history.

Design SlackHard

Deliver messages to large channels, where one message fans out to many thousands of members.