Designing WhatsApp: Real-Time Messaging, Presence, and End-to-End Encryption

Why Study WhatsApp?

WhatsApp handles over 2 billion users exchanging more than 100 billion messages a day, and famously ran this scale on a strikingly small engineering team (fewer than 50 engineers at the time of the Facebook acquisition). Unlike a feed system where staleness is tolerable, a chat system has to get delivery ordering, offline handling, and encryption right - a dropped or duplicated message is a product failure, not a rounding error. Studying WhatsApp reveals how to build stateful, connection-oriented systems at scale, which is a very different problem from the stateless request/response systems most web services are built around.

Requirements Analysis

Functional Requirements

1. 1-on-1 Messaging: Send and receive text, media, and voice messages between two users
2. Group Messaging: Send messages to a bounded group (up to ~1024 members)
3. Online/Last-Seen Status: Show whether a contact is currently online or when they were last seen
4. Delivery Receipts: Track message states - sent, delivered, read (single/double/blue ticks)
5. Offline Delivery: Messages sent to an offline user must be queued and delivered on reconnect
6. End-to-End Encryption: Only the sender and recipient(s) can read message content - not even the server

Non-Functional Requirements

High-Level Architecture

Persistent Connection Architecture

Why WebSockets, Not Polling

HTTP request/response is a poor fit for chat: polling every few seconds wastes bandwidth and adds latency, and long-polling ties up server resources without solving bidirectional push cleanly. WhatsApp keeps a long-lived TCP connection (historically XMPP-based, now a custom binary protocol, conceptually equivalent to a WebSocket) open between each client and one gateway server for as long as the app is in the foreground.

The key insight is that gateway servers are stateful - each one holds an in-memory map of user_id -> socket. This breaks the usual "stateless app server" pattern used elsewhere in web systems, so gateways need their own routing layer in front of them.

Finding the Right Gateway for a User

When Message Service needs to deliver to a recipient, it doesn't know which of thousands of gateway servers holds that user's socket. It looks up a presence/routing table in Redis (user_id -> gateway_id), populated when the client connects and refreshed on every heartbeat, then either:

1. Delivers via that gateway if the entry exists and the gateway confirms the socket is still open (handles the race where a gateway crashed without deregistering).
2. Falls back to the offline mailbox queue if no entry exists, or the gateway reports the socket is gone.

WhatsApp-style systems use the registry approach: it's a small amount of extra latency (a Redis lookup, single-digit milliseconds) in exchange for gateways being freely interchangeable, which matters enormously for rolling deploys and autoscaling a fleet handling hundreds of millions of sockets.

Message Delivery Semantics

The Three Ticks

WhatsApp's delivery receipts map to three states, each written by a different party:

At-Least-Once Delivery + Client-Side Dedup

Network blips mean an ACK can be lost even though the message was delivered - the server can't always distinguish "recipient never got it" from "recipient got it but the ACK didn't make it back." Rather than risk under-delivery, the system resends on ambiguity, giving at-least-once delivery. To make this safe:

• Every message carries a client-generated unique message_id (not server-assigned), so retries are idempotent.
• The recipient's client keeps a small local set of recently-seen message_ids and silently drops duplicates before rendering.
• The server only advances a message from "sent" to "delivered" once it gets an explicit ACK, and retries delivery on a backoff if no ACK arrives within a timeout while the recipient is online.

This combination - server-side at-least-once plus client-side dedup - produces exactly-once behavior from the user's point of view without needing distributed transactions.

Offline Message Queueing

Per-User Mailbox

Every user has a durable mailbox - conceptually a queue keyed by user_id, storing messages addressed to them that haven't yet been delivered. When the presence lookup shows a recipient is offline, the Message Service writes to that mailbox instead of pushing over a socket.

Messages stay in the mailbox until acknowledged as delivered, then get pruned (WhatsApp historically deleted messages from its servers once delivered, syncing only undelivered content - this is a direct consequence of E2E encryption meaning the server has no business retaining plaintext-adjacent content longer than necessary).

Last-Seen and Online Status

Presence Heartbeats

Online status is tracked with lightweight heartbeats rather than being inferred solely from socket state, since a socket can silently die (mobile networks drop connections without a clean TCP close). The gateway expects a heartbeat/ping from the client every N seconds (commonly 30-60s); missing a couple of heartbeats marks the user offline and updates last_seen to the last confirmed activity timestamp.

Privacy Considerations

Presence is one of the more privacy-sensitive features in a chat app:

• Opt-out asymmetry: if a user hides their last-seen, they typically also lose the ability to see others' last-seen - a reciprocity rule to discourage one-sided surveillance.
• Contact-list scoping: presence updates are only pushed to users who share a conversation/contact relationship, not broadcast globally - this bounds fan-out to a person's actual contacts rather than all 2B users.
• Fuzzing granularity: last-seen is often bucketed ("today," "yesterday," rather than exact timestamps) to reduce precise activity tracking.

Group Messaging Fan-Out

Why Groups Don't Scale Like Twitter

A key distinction from feed-fan-out problems (like Instagram's celebrity account problem) is that WhatsApp groups are bounded - capped at around 1024 members - whereas a Twitter-style follower fan-out is unbounded (millions of followers). This bound is a deliberate design constraint, not an accident: it keeps the fan-out cost of every group message small and predictable.

Capping group size is what allows WhatsApp to skip the entire push-vs-pull hybrid model that feed systems need: since the maximum fan-out per message is small and fixed, straightforward per-member delivery through the same offline-mailbox mechanism used for 1:1 chat is sufficient at any group size the product allows.

End-to-End Encryption: The Signal Protocol

End-to-end encryption is the requirement that shapes almost everything else about a chat system's server-side capabilities: since only the two (or group) endpoints can decrypt content, the server cannot do content-based search, spam filtering, or ranking on message bodies - it can only route encrypted blobs. WhatsApp uses the Signal Protocol, at a conceptual level:

Key Agreement (X3DH)

Before two users exchange a single message, their clients perform an Extended Triple Diffie-Hellman (X3DH) key agreement. Each user publishes a bundle of public keys to the server ahead of time (an identity key, a signed prekey, and a batch of one-time prekeys). When Alice wants to message Bob for the first time - even while Bob is offline - she fetches Bob's key bundle from the server and combines several Diffie-Hellman exchanges to derive a shared secret that only Alice and Bob could compute. Critically, this works without Bob being online, because his prekeys were pre-published.

Double Ratchet (Ongoing Messages)

Once the initial shared secret is established, ongoing messages use the Double Ratchet algorithm, which combines two mechanisms:

1. A symmetric-key ratchet that derives a fresh message key for every single message from a continuously-advancing chain, so compromising one message's key doesn't expose others.
2. A Diffie-Hellman ratchet that periodically mixes in a new DH exchange whenever the conversation direction changes, providing "self-healing" - even if an attacker briefly compromises a device's key state, future messages become secure again as new DH values are introduced.

This gives forward secrecy (past messages stay safe if a key is later compromised) and post-compromise security (future messages recover safety after a compromise). The exact key-derivation math is out of scope here - the important takeaway for system design purposes is what the protocol guarantees and what it costs the server.

Database Schema

Conversations

CREATE TABLE conversations (
    id BIGINT PRIMARY KEY,
    type VARCHAR(10) NOT NULL, -- 'direct' or 'group'
    created_at TIMESTAMP DEFAULT NOW()
);
 
CREATE INDEX idx_conversation_type ON conversations(type);

Group Members

CREATE TABLE group_members (
    conversation_id BIGINT NOT NULL REFERENCES conversations(id),
    user_id BIGINT NOT NULL REFERENCES users(id),
    role VARCHAR(10) DEFAULT 'member', -- 'admin' or 'member'
    joined_at TIMESTAMP DEFAULT NOW(),
    PRIMARY KEY (conversation_id, user_id)
);
 
CREATE INDEX idx_group_members_user ON group_members(user_id);
-- Enforced at application layer: max ~1024 rows per conversation_id

Messages

CREATE TABLE messages (
    id BIGINT PRIMARY KEY,           -- client-generated, used for dedup
    conversation_id BIGINT NOT NULL REFERENCES conversations(id),
    sender_id BIGINT NOT NULL REFERENCES users(id),
    ciphertext BLOB NOT NULL,        -- server never sees plaintext
    sent_at TIMESTAMP DEFAULT NOW(),
    -- transient: purged once delivered to all recipients (E2E design goal)
    status VARCHAR(10) DEFAULT 'sent'
);
 
CREATE INDEX idx_messages_conversation ON messages(conversation_id, sent_at DESC);
CREATE INDEX idx_messages_sender ON messages(sender_id);

Delivery Receipts

CREATE TABLE delivery_receipts (
    message_id BIGINT NOT NULL REFERENCES messages(id),
    recipient_id BIGINT NOT NULL REFERENCES users(id),
    status VARCHAR(10) NOT NULL, -- 'sent', 'delivered', 'read'
    updated_at TIMESTAMP DEFAULT NOW(),
    PRIMARY KEY (message_id, recipient_id)
);
 
CREATE INDEX idx_receipts_recipient ON delivery_receipts(recipient_id, status);

Operational Strategy: Connection and Queue Scaling

Gateway Capacity Planning

Each gateway server holds one socket per connected user, so capacity is bounded by file descriptors and per-connection memory rather than CPU. A single modern server can hold on the order of 1-2 million idle WebSocket connections with careful tuning (epoll-based event loops, minimal per-connection memory footprint). At 2B users with a fraction concurrently online, this still requires thousands of gateway servers, each registering its held connections into the shared Redis presence registry.

Mailbox and Queue Backpressure

Scaling Challenges & Solutions

Key Takeaways

1. Stateful gateways need their own routing layer: unlike stateless API servers, WebSocket gateways hold state (the socket), so you need a presence registry to route to the right one
2. At-least-once + client dedup beats trying for exactly-once server-side: idempotent client-generated IDs make retries safe without distributed transactions
3. Offline delivery is a queue problem, not a database problem: a per-user mailbox that drains on reconnect is simpler and more scalable than polling
4. Bounding group size sidesteps the celebrity fan-out problem entirely: a hard cap on membership avoids the push/pull hybrid complexity feed systems need
5. End-to-end encryption is a product tradeoff, not just a crypto checkbox: it forecloses server-side content features, which should shape the rest of your design

Follow-Up Questions to Consider

1. How would you support multi-device sync (same account logged in on phone + web + desktop simultaneously)?
2. How would you design encrypted media (photos/videos) attachments, given E2E means the server can't preview or transcode them?
3. How would you handle a group admin removing a member mid-conversation - what happens to encryption keys?
4. How would you build spam/abuse detection without reading message content?
5. How would you design "message backup to cloud" while preserving end-to-end encryption guarantees?