Design Whatsapp | System Design Question

"Design WhatsApp" looks like a duplicate of the standard messaging-app question, and candidates treat it like one - WebSocket, chat servers, a big message store, presence, push. That answer is fine for Telegram or Slack and wrong for WhatsApp, because it misses the two decisions that actually define WhatsApp: it is end-to-end encrypted, so the server can never read a message, and it is store-and-forward, so the server deletes a message the moment it's delivered and keeps nothing permanently. Those two choices reinforce each other and rewrite storage, multi-device, and receipts.

WhatsApp keeps the standard real-time skeleton - WebSocket connections, chat servers, service discovery, a presence heartbeat, push notifications - so this post spends its time on what actually makes WhatsApp WhatsApp: no server-side history, encryption the server is locked out of, and how multi-device and receipts survive both constraints. Same 60-minute interview shape, aimed at the parts that differ.

Step 1: Scope it - the answers that make this WhatsApp, not Messenger

The clarifying round is short here, because the interesting answers are the ones that pin down the two defining decisions. A realistic exchange:

You: Is end-to-end encryption in scope, or a nice-to-have? For WhatsApp it changes the core design, so I want to fix it up front. Interviewer: In scope. It's on by default for every message.

You: Then does the server keep chat history at all, or only relay messages and forget them once delivered? Interviewer: Relay and forget. The server shouldn't hold a permanent copy.

You: Multi-device? A phone plus web and desktop, all working even when the phone is off? Interviewer: Yes - up to a handful of linked devices, and the phone doesn't have to be online.

You: Group size, and the receipt behaviour - the sent/delivered/read ticks? Interviewer: Groups up to about a thousand members. And yes, the three tick states.

Notice what those answers foreclose. "On by default" plus "relay and forget" together kill the entire message-store subsystem from the standard design - there is no key-value store of history to shard, because there is no history on the server. That is the opposite of the assumption most candidates walk in with, which is why asking beats assuming. Written as precise scope:

Functional requirements

• One-on-one and group chat (groups up to ~1024 members), text and media.
• End-to-end encryption on by default for every message - the server only ever sees ciphertext.
• Store-and-forward delivery - the server holds a message only until delivered, then deletes it; undelivered messages expire after a bounded window.
• Multi-device - up to a handful of linked devices, each working independently, the phone not required to be online.
• Delivery and read receipts (sent, delivered, read).
• Push notifications and presence (built the standard way).

Non-functional requirements

• Confidentiality - no one but the sender and recipients, WhatsApp included, can read message content.
• Low latency and high availability on the delivery path.
• Massive scale - WhatsApp delivers on the order of 100 billion messages a day.
• Minimal server-side data at rest - deleting on delivery is a feature, not an oversight.

The scale line is worth a beat: WhatsApp famously ran this for hundreds of millions of users on a small Erlang-based backend, precisely because store-and-forward keeps the server stateless about content - it moves bytes and forgets them, rather than maintaining a giant database of everyone's conversations.

Store-and-forward: the server is a post office, not an archive

Start with the storage decision, because everything else bends around it. In the standard design the server is the source of truth: it persists every message and serves history back on demand. WhatsApp inverts that. The server is a post office - it accepts a sealed envelope, holds it only long enough to hand it over, and then discards it. The durable copy of your chat lives on your devices, nowhere else.

Concretely, per WhatsApp's own privacy policy: messages are not retained in the ordinary course of delivery; once delivered, they are deleted from the servers. If the recipient is offline, the message is kept in encrypted form for up to 30 days while delivery is retried, and if it is still undelivered after 30 days it is deleted. The server is a bounded delivery buffer, not an archive.

Why forget on delivery? Three reasons, and naming all three is the strong answer:

1. Encryption makes stored ciphertext worthless to the server. Because messages are end-to-end encrypted (next section), a permanent server copy would be an archive of blobs WhatsApp cannot decrypt. Keeping it buys nothing.
2. You can't leak or be compelled to hand over what you don't have. Deleting on delivery is the strongest possible privacy stance - the data simply isn't there. It's why WhatsApp's answer to a content request is "we don't retain it."
3. Cost. At ~100 billion messages a day, a keep-everything store is enormous and permanent. Store-and-forward turns storage from an ever-growing archive into a small, self-draining buffer.

The cost of this choice is the mirror image of a keep-everything design's benefit: a brand-new device gets no history from the server, because there's none to get. That single consequence is what makes WhatsApp's multi-device and backup stories genuinely hard - we'll deal with both below. The other side of this fork is the server-as-source-of-truth model, where the server keeps every message and serves it back on demand; WhatsApp gives that up on purpose.

End-to-end encryption: the server carries a sealed envelope

End-to-end encryption (E2E) means the message is encrypted on the sender's device and only decrypted on the recipient's - the server, and anyone tapping the wire, sees ciphertext and nothing else. WhatsApp implements the Signal Protocol; the mechanics are public in WhatsApp's encryption whitepaper. We'll stay non-mathematical - just what actually happens.

The pieces you should be able to name:

• Keys live on devices, never on the server. Each device generates a long-term identity key plus a batch of shorter-lived prekeys, and publishes only the public halves to the server. The private halves never leave the device. The server's job is to hand out public keys so senders can start a session - it is a key directory, not a key holder.
• A pairwise session per contact. The first time A messages B, A fetches B's public key bundle and derives a shared secret (a Diffie-Hellman key agreement - both sides mix their keys to compute the same secret without ever transmitting it). From then on A and B share an encrypted session.
• Forward secrecy via a ratchet. The session doesn't reuse one key; it ratchets forward, deriving a fresh key for every message. If one message's key is ever compromised, past and future messages stay safe. This is the Double Ratchet at the heart of the Signal Protocol.
• Groups use Sender Keys, so encryption doesn't blow up. Encrypting a group message separately for every member would be brutal - a 1000-person group would mean ~1000 encryptions per message. Instead each member generates a Sender Key for the group and distributes it once (over the pairwise sessions) to the others. To post, the sender encrypts the message once with its Sender Key and the server fans the single ciphertext out to everyone; each member decrypts with the sender key they already hold. One encryption, server-side fan-out, still end-to-end encrypted.

The load-bearing takeaway for the design: the server is deliberately locked out of content. That is why a permanent store makes no sense, and why every content-dependent feature you'd normally push to the server (search, spam classification on message text, server-rendered previews) has to move to the client or be given up.

Multi-device without server history: client-fanout

Here is the genuinely hard problem, and a favourite senior-level probe: if the server keeps no history and can't read anything, how do a phone, a laptop, and a desktop all stay in sync?

WhatsApp's original answer was a cheat: the phone was the source of truth, and the web client was just a mirror that relayed through the phone - so if your phone was off, web didn't work. The 2021 multi-device architecture removed that. The approach is client-fanout, and the key idea is that each device is its own first-class cryptographic identity:

• Every device - phone, laptop, desktop - has its own identity key and its own encrypted session with each of your contacts' devices. No device decrypts another's messages.
• When A sends to B, A's device encrypts the message once per destination device and transmits N copies - one for each of B's devices and one for each of A's own other devices (so they all show the sent message). The server just routes the N sealed copies.
• Because each device has its own session, the phone no longer has to be online - your laptop talks to B's devices directly through the server.

The trade-off is fan-out cost that scales with device count: a message to a contact with 3 devices is 3 encryptions and 3 sends; a group multiplies that across members and their devices. That is the concrete reason WhatsApp caps you at 4 companion devices - it bounds the blow-up. Name that cap and why it exists and you've answered the follow-up before it's asked.

One honest gap: because the server has no history, a freshly linked device can't download your past chats from the server - there aren't any. WhatsApp handles this by securely transferring a slice of recent history from an already-linked device at link time (itself end-to-end encrypted), not by reading it off a server. Full history restore is a separate mechanism: backups.

Delivery and read receipts under store-and-forward

The ticks map cleanly onto the store-and-forward flow, and interviewers like to check you can place each one:

• One grey tick - sent. The ciphertext reached the server. The server has it buffered but the recipient doesn't yet.
• Two grey ticks - delivered. It reached at least one of the recipient's devices, which sent back a delivery receipt. This is also the trigger that lets the server delete the message - its job is done.
• Two blue ticks - read. The recipient opened the chat, and their device emitted a read receipt.

Receipts are themselves small messages that flow backwards from recipient to sender. Two points that show depth: the delivered receipt is what authorises the server to drop the buffered copy, so receipts and store-and-forward are coupled, not independent; and read receipts are a client-side privacy toggle - turn them off and your device simply never emits the read receipt, so the sender's message never turns blue (per WhatsApp's help center). In a group, delivered/read are tracked per member - the sender collects a receipt from each recipient's device.

Follow-up questions to expect

• If the server keeps nothing, how do I get my chats on a new phone? Backups - the deliberate escape hatch. Chats are backed up to the user's own cloud (iCloud or Google Drive), and WhatsApp offers end-to-end encrypted backups locked by a user-held key or password, so even the backup is unreadable to WhatsApp and the cloud provider. History restore is a client pulling and decrypting its own backup, never the WhatsApp server replaying messages.
• So WhatsApp knows nothing about me? It can't read message content, but it still has metadata - who messages whom, when, group membership, your profile and contacts, last-seen. E2E protects content, not the social graph. A precise candidate draws that line rather than overclaiming.
• How do media files work if the server can't read them? The sender encrypts the file with a random key, uploads the ciphertext blob to a media store, and sends the recipient the decryption key and URL inside the E2E-encrypted message. The blob store holds only ciphertext; forwards reuse it by re-sharing the key, which is why WhatsApp can retain popular media briefly without ever seeing it. Delivery rides a CDN, and uploads/downloads typically use short-lived presigned URLs.
• Ordering and offline delivery without a server log? The sender's session assigns a per-session counter, so the recipient orders and de-duplicates on its own; the server only needs to buffer-and-retry within the 30-day window and fire a push notification to wake an offline device.
• What about "View Once" or disappearing messages? These are client-enforced - the message carries a flag, and recipient clients honour it by deleting after viewing or after a timer. The server still just relays; it can't enforce something it can't read.
• Group scale to 1024 members? Sender Keys keep per-message encryption at one operation regardless of group size; the server does the fan-out. The pressure moves to fan-out volume and key distribution when membership changes (every member rotates the sender key when someone leaves, for forward secrecy).

Wrap up

WhatsApp is a standard messaging app with two decisions flipped, and everything distinctive follows from them. End-to-end encryption locks the server out of content, which makes a permanent message store pointless - so WhatsApp is store-and-forward: the server buffers a message, deletes it on delivery, and holds an undelivered one for at most 30 days. Because the server keeps no history and can't read anything, the design pushes work to the clients: client-fanout multi-device where each device is its own encrypted identity (capped at 4 companions to bound fan-out), client-held backups as the only way to restore history, and receipts and disappearing-message rules enforced on the device. The real-time transport underneath - WebSocket, chat servers, presence, push - is standard; what changes is that the server became a post office that forgets.

The one-line version to leave the interviewer with: WhatsApp optimizes for the server knowing as little as possible - and store-and-forward plus end-to-end encryption is how it gets there. For the timing that keeps a design like this inside the hour, see the 60-minute interview framework.