Design WhatsApp

Hard45 min
1 / 30
System design answer

Design WhatsApp

Hard45 min30 sections
understanding•10 min read

Problem Statement: Encrypted Store-and-Forward at a Billion Sockets

Frames WhatsApp as a connection-tier problem wrapped in a cryptography problem, not a CRUD chat app.

Problem statement

Design a mobile-first messenger that delivers end-to-end encrypted text and media between individuals and groups, works when either endpoint is offline, shows delivery and read receipts, and sustains planet-scale concurrency. WhatsApp publicly reports more than two billion monthly active users and on the order of one hundred billion messages per day, and its public engineering history describes an Erlang-on-FreeBSD connection tier carrying millions of sockets per node. Those are cited public signals; every other number in this answer is an explicit design assumption.

The defining tension is that the server must route and queue content it cannot read. After the 2016 rollout of the Signal Double Ratchet across all chats, the backend sees ciphertext envelopes, not message bodies. Therefore ordering, deduplication, pending queues, fan-out and retention must all be engineered over metadata and opaque blobs. A candidate who designs plaintext chat queues has missed the question.

Why this problem is distinctive

Three properties separate this design from a generic notification system. First, durability is temporary: the server is a store-and-forward relay that deletes ciphertext once every intended device acknowledges it, so the queue is a hot, short-lived dataset with strict per-device ordering. Second, the connection tier is the product: a message is only as fast as the last persistent socket it reaches, so socket sharding, session resume and presence storms dominate the architecture. Third, cryptography is a scaling concern, not a footer: multi-device identities, one-time prekey exhaustion, and group sender-key rotation change write amplification and failure modes.

The four planes

  1. Connection plane: persistent sockets, session resume, presence, typing, receipt transport.
  2. Message plane: conversation ordering, ciphertext relay, pending queues, group fan-out, receipts state.
  3. Media plane: client-encrypted blob upload, object storage, CDN egress, lifecycle deletion.
  4. Trust plane: identity keys, prekeys, sender keys, device graph, reporting and abuse controls at architecture level.

A strong interview answer keeps these planes separate, states which dataset owns ordering, and never lets a presence write block a ciphertext delivery.

Key Highlights

  • •Public signal: 2B+ MAU and ~100B messages/day per WhatsApp public statements; all other numbers here are labeled assumptions.
  • •The server routes ciphertext it cannot read: ordering, dedupe and queues run over metadata and opaque blobs.
  • •Store-and-forward means durability is temporary: delete-on-ack makes the pending queue a hot short-lived dataset.
  • •Four planes: connection, message, media, trust; each has its own consistency and retention model.
  • •Group scale is a crypto-scaling problem: sender keys avoid pairwise O(n) encryption per group message.
Lead With Ciphertext-Blind Relay
State in the first two minutes that the server orders, queues and fans out content it cannot decrypt. Every later choice — dedupe by message ID, metadata-only analytics, delete-on-ack — follows from that sentence.
Do Not Design a CRUD Chat App
A design centered on a messages table with plaintext rows fails the encryption requirement and the retention model. The relay holds ciphertext briefly; devices hold history.

Section Rescue Kit

Buzzwords to use:

Store-and-Forward RelayCiphertext-Blind Ordering

Safe statements:

  • "Let me separate what the server can see — metadata and ciphertext — from what only devices can see — plaintext history."
  • "Before choosing stores, I will state which dataset is temporary (pending queues) and which is durable (device history, key registry)."
Design WhatsApp - System Design | WinJob | WinJob