Skip to content
sysgeeks

Design WhatsApp: a system design interview walkthrough

Design a secure, real-time chat service by following one message from sender to recipient. This walkthrough focuses on delivery guarantees, offline devices, multi-device encryption, and the failures that change the architecture. It is an interview proposal, not a description of WhatsApp's private production systems.

By SysGeeks

Practise chat message storageStart a timed mock interview

Clarify the scope and guarantees

Start with one-to-one text messages and small groups. Users can connect from several devices, send while a recipient is offline, see delivery state, and keep message contents private from the service. Defer calls, large groups, search, backups, and media processing until the core delivery path is clear.

  • A sender can retry after a timeout without creating a second visible message.
  • A message is acknowledged only after the system has accepted responsibility for it.
  • Delivery is at least once across retries; clients deduplicate by stable message ID.
  • Each device receives ciphertext it can decrypt, while the server routes without message plaintext.

State the retention promise explicitly. This proposal stores encrypted messages only until each target device acknowledges delivery or the message expires. A system that supports durable history and multi-device recovery needs a different storage and backup contract.

Estimate message and connection load

Use labeled assumptions rather than claiming real WhatsApp traffic. Suppose 100 million daily users send 40 messages each: 4 billion messages per day, about 46,000 per second on average. A 10× peak is roughly 460,000 messages per second before multi-device fan-out, retries, receipts, and group expansion.

Persistent connections add a separate capacity problem. If 50 million devices are connected at once, gateway memory, heartbeat traffic, reconnect storms, and regional failover matter as much as message throughput. Measure both the number of live connections and the oldest undelivered message.

A defensible high-level design

  1. 1

    Client and key directory

    Clients hold private keys and encrypt message content. A directory returns the current set of recipient device identities and public keys; it does not expose private keys to the service.

  2. 2

    Connection gateways

    Maintain authenticated persistent connections and route a device to its home gateway. Keep connection state in memory, with a registry or lease so another service can locate the active connection.

  3. 3

    Message ingress

    Validate the sender, assign or verify a stable message ID, apply abuse and size limits, and resolve the recipient device list. Avoid logging plaintext or sensitive message metadata.

  4. 4

    Durable delivery queue

    Write encrypted envelopes to a partition keyed by recipient device. The successful durable write is the sender's acceptance point; partitioning by recipient preserves per-device ordering where required.

  5. 5

    Delivery workers

    Deliver queued envelopes over the recipient's live connection. Retry after disconnect, deduplicate by message ID, and remove an item only after the recipient's defined acknowledgement.

  6. 6

    Push notification service

    When no device is connected, send a minimal wake-up signal through the platform push service. The client reconnects and fetches ciphertext from the queue; push delivery is not treated as reliable message delivery.

  7. 7

    Receipt and group services

    Track delivery and read receipts as separate events. For groups, resolve membership and fan out to recipient devices in bounded batches, with explicit limits and retry state.

Trace a message from send to delivery

  1. The sender encrypts the message for the recipient's current devices and submits envelopes with one message ID.
  2. Ingress checks authorization and limits, resolves device keys, and writes the envelopes to durable recipient queues.
  3. After the durable write, the sender receives an accepted acknowledgement; this does not mean a recipient has received it.
  4. Delivery workers push envelopes to online devices. Offline devices keep their envelopes until reconnect or expiry.
  5. A client stores the message locally, deduplicates retries, and acknowledges the message ID. The service records a delivery receipt.
  6. For a group, fan-out proceeds in bounded batches. Partial progress is durable so a worker retry does not restart the whole group.

Separate accepted, delivered, and read states. A single “sent” flag cannot explain whether the message is safe to retry, waiting for an offline device, or already shown to a person.

Multi-device fan-out changes the cost model

If one account has several devices, the sender may encrypt a copy for every device instead of asking the server to decrypt once and redistribute plaintext. This preserves end-to-end encryption but multiplies encryption work, queue writes, and delivery state. A device added or revoked while a send is in flight also makes the recipient list time-sensitive.

Meta has described WhatsApp's multi-device approach as client fan-out: the sending client encrypts and transmits separately for the sender's and recipient's devices. That public description is a useful source for this trade-off, not a complete blueprint for the service. For the exercise, version the device list and define whether a message targets the snapshot taken at send time or triggers a retry after the list changes.

Failures that expose gaps in the design

Ingress times out after queue commit
The client retries with the same message ID. Ingress returns the original acceptance result, and the queue's idempotency key prevents a duplicate.
A gateway dies with millions of open connections
Clients reconnect with jitter to another gateway. The connection registry expires stale leases, and message delivery resumes from durable queue state.
A recipient disconnects after receiving but before acknowledging
The envelope may be sent again. The client deduplicates by message ID before displaying it, then repeats the acknowledgement.
A push provider is delayed or unavailable
Keep the encrypted message in the queue and retry push within limits. The client can still fetch messages on its next reconnect; push is only a wake-up optimization.
A group fan-out worker crashes halfway through
Persist per-recipient progress and retry the remaining batch. Use stable message IDs and idempotent queue writes to tolerate replay.
An account revokes a linked device
Stop issuing new envelopes to that device after the key directory commits the revocation. Define how already queued ciphertext expires or is cancelled; do not claim revocation can erase a message already delivered.

A concise interview answer

“I'll design one-to-one and small-group text messaging first. Clients encrypt for the recipient's devices, then submit stable message IDs to an ingress service. We acknowledge after encrypted envelopes reach a durable, per-device queue. Gateways deliver to online clients over persistent connections; offline messages wait in bounded queues, and push notifications only wake clients. Retries are at least once, so clients deduplicate before displaying and acknowledge after local persistence. I'll next test reconnect storms, group fan-out, device revocation, and the privacy cost of receipts.”

Then let the interviewer choose the next deep dive: large groups, media delivery, encrypted backups, calls, abuse controls, or multi-device history sync. Keep each feature's privacy and delivery guarantee explicit.

Published sources and scope

The architecture and capacity values on this page are SysGeeks interview assumptions. They are not claims about WhatsApp's private production design or current traffic.

WhatsApp system design interview questions

How do you design WhatsApp in a system design interview?
Separate connection management from durable message state. Route each sender's encrypted message through a connection gateway to a recipient's devices, acknowledge a durable enqueue, and deliver over a persistent connection when a device is online. Keep a bounded per-device offline queue, deduplicate retries by message ID, and use push notifications only to wake offline clients.
Does this walkthrough describe WhatsApp's actual architecture?
No. It is an original interview design with explicit assumptions. The linked Meta Engineering articles document specific WhatsApp systems and security choices; they do not reveal every internal service or the complete production architecture.
How should a chat system handle offline users?
Persist encrypted messages in a bounded queue keyed by recipient device. Retry delivery after reconnect, remove a queued item only after the chosen delivery acknowledgement, and expire or reject messages according to a stated retention policy. A push notification is a wake-up hint, not the message source of truth.
How does multi-device delivery affect message encryption?
A sender may need to encrypt a message separately for each recipient device, which increases work and bytes with the number of devices. Maintain a current device list, handle devices added or revoked during delivery, and keep private keys on clients. Meta has publicly described this client-fanout approach for WhatsApp multi-device messaging.