How does WhatsApp deliver a message in real time?

Each phone holds a long-lived, persistent connection (a WebSocket-style socket, historically over XMPP) to a chat server, so the server can push a message down the instant it arrives rather than the phone polling for it. When you send a message it goes to the server, which looks up the recipient's connection and pushes it to their device. If the recipient is offline, the server stores the message and delivers it — and the queued delivery receipts — the moment they reconnect.

How do the one, two, and blue check marks work?

They are delivery and read receipts, and each is an acknowledgement traveling back up the chain. One grey tick means the server received your message. Two grey ticks mean it was delivered to the recipient's device (their phone ACKed it). Two blue ticks mean the recipient's app reported the chat was opened and the message read. Each state is a small ack message flowing the opposite direction of the original, which is why they can lag when someone is offline.

How does WhatsApp guarantee a message is never lost?

With acknowledgements and store-and-forward. The sender keeps a message marked 'pending' until the server acks it; the server persists the message durably before acking, then keeps it until the recipient's device acks delivery. If the recipient is offline the message sits in their server-side queue. Retries plus idempotent message IDs mean a dropped connection causes a resend, not a lost or duplicated message — the message ID lets the receiver discard a duplicate.

How is message ordering kept consistent?

Each message carries a monotonically increasing sequence number or timestamp scoped to the conversation, and the recipient's client orders by it, buffering briefly to reabsorb any out-of-order arrivals from retries. Routing a given conversation's messages through the same server or partition keeps a single ordering authority, so two people in a chat see the same sequence even though the network delivers packets unpredictably.

How does group messaging scale to hundreds of members?

The sender uploads the message once, and the server fans it out — it looks up every group member's connection and pushes a copy to each, queuing for anyone offline. This server-side fan-out means the sender's phone doesn't send N copies over its own limited uplink. For encryption, WhatsApp uses the Signal 'sender keys' scheme so a group message is encrypted once per sender rather than separately for every recipient, keeping large groups practical.

How does end-to-end encryption work here?

WhatsApp uses the Signal Protocol. Messages are encrypted on the sender's device with keys only the participants hold, so the server relays ciphertext it cannot read. The Double Ratchet algorithm rotates keys per message for forward secrecy (a stolen key can't decrypt past messages). The trade-off is that server-side features like search must happen on-device, and multi-device support requires syncing keys securely across a user's own devices.

How does presence — 'online' and 'typing…' — work?

Presence is ephemeral, high-churn state that is deliberately not stored durably. When you open a chat, your device subscribes to the other person's presence; their 'online' and 'typing…' events are pushed only to the currently subscribed watchers and kept in memory, not written to the main database. Because it changes constantly and matters only in the moment, presence is optimized for freshness over durability — losing it on a server restart is fine.

How does it handle billions of users and connections?

By keeping per-connection work cheap and sharding everything. Connections are spread across many chat servers built for massive concurrency (WhatsApp famously ran millions of connections per box on Erlang), a session registry maps each user to the server holding their live socket so messages can be routed to it, and users and message queues are partitioned by user ID. Offline queues and media live in separate horizontally-scaled stores, so no single component owns all the traffic.

Design WhatsApp — A Guided System Design

System Design · step by stepDesign WhatsApp

Step 1 / 10

Deep cut · 11:53

Watch one message wait all night, then find out what the second tick actually does

The interactive walkthrough above lays out the relay, the persistent socket, the session registry, the acknowledgement protocol, group fan-out and end-to-end encryption. This film starts from a moment you have already lived — you send a message at midnight, it gets one grey tick, and at seven in the morning it becomes two while the other phone was switched off the whole time — and refuses to explain it until you have watched two phones talking directly fail. Everything hangs on three problems you carry for twelve minutes: hold it, push it, prove it.

See why the obvious build dies: a phone sits behind a carrier address shared by thousands and changing as it moves, so nothing outside can dial it — which is why the fix is that NEITHER phone ever answers a call, and both of them place one.
See what the grey tick really is: not a slow message, but a message sitting in a queue with the recipient’s name on it — and the second tick is not a status, it is the instruction that deletes it.
Take it into the interview: derive store-and-forward, the per-user inbox queue, the held-open connection, the session registry and the three-stage acknowledgement ladder — each from the number that demanded it, with what it costs said out loud.

Design WhatsApp: Where Your Message Waits All Night — System Design Masterclass thumbnail

In the interview room

How you’d open this design in an interview

Before any boxes: agree what it must do, pin the qualities that shape everything, then build — naming each trade-off as you make it. The walkthrough above is that exact order.

Functional requirements

What it must do — agree on these before drawing a single box.

Send 1:1: Alice sends a message to Bob and it reaches him — whether he is online, offline, or on another continent.
Deliver live: when Bob is connected the message lands in milliseconds, pushed rather than polled for.
Survive offline: if Bob is unreachable the message waits, and drains the moment he reconnects.
Receipts: ✓ sent, ✓✓ delivered, blue ✓✓ read — each tick backed by a real acknowledgement.
Groups: one message from one sender reaches every member of a group.
Media: photos and video attach to a chat without being pushed down the message socket.
End-to-end encryption: only the participating devices can read a message — the servers relaying it cannot.

Non-functional requirements

The qualities that shape the whole design — each one names the mechanism that buys it.

A message is never lost, even to a phone that is off: The relay stores each message before forwarding it, and an unreachable recipient gets a per-user Inbox Queue that holds the message until reconnect. Store-and-forward is what makes messaging survive flaky networks and sleeping phones.
Delivery feels instant, not polled: Each phone holds a persistent WebSocket to a Connection Server, so the server pushes the moment a message arrives rather than waiting for the client to ask. Polling would put a lag floor under every message.
Find the right server out of thousands: A Session Service maps user → the connection server currently holding their socket, so “deliver to Bob” becomes one lookup and one push, not a broadcast to every server.
The ticks mean something: Each tick is a distinct acknowledgement travelling back: the server confirms receipt (✓), the recipient device confirms delivery (✓✓), and the recipient app confirms the chat was opened (blue ✓✓). The UI is the visible edge of an ack protocol.
A group message does not melt the sender: The sender uploads one message; the server fans it out to each member’s connection or queue. Fan-out happens once, server-side, so the sender’s phone pays for one send regardless of group size.
A video does not block the chat: Media goes out-of-band — the client uploads to a blob store and sends only a reference over the socket, so a large upload never occupies the path that ordinary messages travel.
The operator cannot read messages: Keys live on the devices. The sender encrypts for the recipient’s device and the servers relay ciphertext they have no key for, so “trust us” is replaced by “we are unable to”.
Billions of phones on a modest fleet: Connections are cheap when they are idle — each connection server is tuned to hold on the order of ~2 million open sockets, so the fleet is sized by concurrent connections rather than by registered users.

The trade-offs you say out loud

Senior signal isn’t the boxes — it’s naming what you gave up and why it was the right price.

A relay that stores then forwardsover phones connecting directly to each other

Phones sit behind carrier NAT, change IP as they move, and sleep to save battery — a direct connection rarely establishes and constantly breaks. A middleman both sides can always reach is also the only place a message can wait while one side is offline.

A persistent WebSocket the server pushes overover the client polling for new messages

Polling puts a floor under latency and wastes most requests returning nothing. Holding an idle socket costs memory but almost no CPU, so pushing is both faster and cheaper at this scale.

A session registryover asking every connection server whether it holds the recipient

A broadcast is O(servers) work for every single message and couples every server to every other. One registry lookup turns routing into a constant-cost step and lets you add servers without rewiring anything.

Deleting a message once deliveredover keeping chat history on the server

Server-side history would make multi-device sync and restore trivial — and would also make the servers a target worth attacking and a subpoena worth serving. Holding a message only until it is delivered means there is little to hand over.

Fan-out on write for groupsover each member pulling the group’s messages

Push keeps delivery uniform: a group message travels the same path as a 1:1 one and arrives without the recipient asking. The cost is N queue writes per message, which is why group size is capped rather than unbounded.

Media out-of-band via a blob storeover sending bytes over the message socket

The socket is shared by every message on that connection; a 60 MB video would occupy it for seconds and delay everything behind it. Uploading separately and sending a reference keeps the message path small and predictable.

End-to-end encryptionover server-side plaintext

Plaintext on the server would enable search, cloud history and server-side spam filtering. Encrypting end to end gives those up in exchange for a guarantee that survives a breach or a legal order — for a messenger, that guarantee is the product.

What this teaches

How a message gets from one phone to another when neither can be reached directly: store-and-forward through a relay, a persistent socket so delivery is a push rather than a poll, a registry that says which server holds the recipient, a per-user queue for when nobody is home, and an acknowledgement protocol that turns all of it into two grey ticks and one blue pair.

Key takeaways

Store-and-forward server — the relay spine between two phones.
Persistent WebSockets so the server pushes messages instantly.
A Session registry routes each message to the right connection server.
Per-user Inbox Queues hold messages for offline recipients.
Acknowledgements drive the ✓ / ✓✓ / blue-tick delivery receipts.
A Group Service fans one message out to every member.
Media via blob storage + CDN; only a tiny pointer rides the chat.
~2M sockets per server and end-to-end encryption at planet scale.

Concepts covered

What is WhatsApp, really?
Two phones, one server
Reach Bob the instant it lands
Which server is Bob on?
Deliver to someone offline
✓ sent, ✓✓ delivered, ✓✓ read
One message, many phones
Don't push a video down the socket
2 billion phones, zero peeking

Design WhatsApp — read the full walkthrough as text

the same steps, decisions & trade-offs, for reading, reference & search

The big idea

What is WhatsApp, really?

Strip away the brand and WhatsApp does one magical thing: get a message from your phone to anyone else's — instantly, reliably, anywhere on Earth — and tell you the moment they've read it.

That one sentence hides brutal questions. How do two phones that can't talk directly reach each other? What if the other person is offline? How do you do this for 2+ billion people at once — and prove delivery with those little ✓✓ ticks?

How to read this: We add one piece at a time. Each step opens with a problem, then the smallest fix. Watch the diagram grow and the chat below come alive — by the end you'll have built the whole thing. Hit Begin.

Step 1 · The skeleton

Two phones, one server

Alice's phone and Bob's phone can't message each other directly — phones hide behind carrier networks, change IPs, and fall asleep. They need a middleman both can reach.

Design decision: Two phones behind carrier networks, changing IPs, falling asleep — they can’t talk directly. How do they exchange messages?

The call: A server in the middle that stores then forwards each message. — Alice sends to the server, which holds a copy in a Message Store and forwards to Bob. Store-and-forward — holding each message until the recipient has it — is what lets messaging survive flaky networks and sleeping phones.

Put a server in the middle. Alice sends her message to the server; it saves a copy in a Message Store and forwards it to Bob. The classic client → server → client relay — the spine of every chat app.

Store and forward: The server doesn't just pass messages along — it holds each one until the recipient has it. That single idea is what lets messaging survive flaky networks and sleeping phones.

Step 2 · Always-on

Reach Bob the instant it lands

The server is holding Alice's message — but Bob's phone isn't asking for it. Polling "any messages for me?" every second, for billions of phones, would melt the planet and still feel slow.

Design decision: The server holds Alice’s message, but Bob’s phone isn’t asking for it. How does it arrive instantly?

The call: A persistent WebSocket per phone; the server pushes on arrival. — An always-open socket flips the model — the server speaks first, delivering the moment a message lands, with no polling. One warm pipe carries messages, typing dots and receipts both ways.

Keep a persistent connection — a WebSocket — open between every phone and a Connection Server. Now the server can push the moment a message arrives. No refreshing, no polling; the pipe stays warm as long as you're online.

Push, don't poll: A WebSocket flips the web's usual model: instead of the client always asking, the server speaks first. One always-open pipe carries messages, typing dots and receipts in both directions.

Step 3 · The address book

Which server is Bob on?

At scale there isn't one connection server — there are thousands. Alice's socket lands on server #14; Bob's on server #882. Server #14 holds the message but has no idea where Bob is.

Design decision: There are thousands of connection servers. Alice is on #14, Bob on #882. How does #14 deliver to Bob?

The call: A Session Service maps user → connection server; look Bob up and route. — When Bob connects he registers his spot; to deliver, #14 asks "where’s Bob?", finds #882, and routes straight there. Service discovery turns "shout to everyone" into "deliver to exactly one place" — a fast in-memory registry (Redis).

A Session Service keeps a live registry: user → connection server. When Bob connects he registers his spot. To deliver, server #14 asks "where's Bob?", finds server #882, and routes the message straight there.

Service discovery: The registry turns "shout to everyone" into "deliver to exactly one place." It's usually a fast in-memory store (Redis), updated every time someone connects, disconnects, or roams to a new server.

Step 4 · When Bob's asleep

Deliver to someone offline

Bob's phone is off, or he's on the subway with no signal. There's no socket to push to. The message can't just vanish — and Alice shouldn't have to wait or retry.

Design decision: Bob’s phone is off or has no signal — there’s no socket to push to. What happens to the message?

The call: Queue it in Bob’s per-user Inbox Queue; drain on reconnect, then delete. — If the registry shows no live connection, the message waits in Bob’s mailbox; the moment he reconnects the server drains the queue to his phone, confirms delivery, and deletes the stored copy. The queue decouples send from receive.

If the registry shows Bob has no live connection, drop the message into his Inbox Queue — a per-user mailbox. The moment Bob reconnects, the Connection Server drains his queue to the phone, confirms delivery, and the stored copy is deleted.

Queues absorb reality: A message queue decouples "send" from "receive." Senders never block on a sleeping recipient; the queue patiently holds messages until the device shows up — seconds or days later.

Step 5 · The famous ticks

✓ sent, ✓✓ delivered, ✓✓ read

Alice wants to know what happened to her message. Did it leave her phone? Reach Bob's? Did he actually read it? Silence breeds anxiety.

Every hop sends a tiny acknowledgement back. Reaches the server → one ✓. Delivered to Bob's device → two ✓✓. Bob opens the chat → his phone reports it and the ticks turn blue. A little state machine riding the same socket.

Acks all the way down: Reliable delivery means confirmations at every step. The ticks aren't decoration — they're the visible edge of the acknowledgement protocol that guarantees no message is silently lost.

Step 6 · Group chat

One message, many phones

Alice posts in a 50-person group. We can't make her phone send 50 copies — that's slow and drains her battery. But everyone must get it, in order.

Design decision: Alice posts in a 50-person group. How does everyone get it, in order, without her phone sending 50 copies?

The call: She sends one message; a Group Service fans it out to each member. — One message tagged with the group id; the Group Service looks up members and fans out a copy to each one’s connection (or Inbox Queue if offline). One send in, N deliveries out, all server-side — fan-out on write.

She sends one message tagged with the group id. A Group Service looks up the members and fans out a copy to each one's connection — or their Inbox Queue if offline. One send in, N deliveries out, all handled server-side.

Fan-out: Fan-out is the heart of group messaging. WhatsApp fans out on write — copying to each member the instant the message lands — which keeps delivery fast for the small-to-medium groups it's tuned for.

Step 7 · Photos & video

Don't push a video down the socket

A 50 MB video can't ride the same lightweight pipe as "lol 😂". Pushing big blobs through connection servers would clog the real-time path for everyone.

Design decision: A 50 MB video can’t ride the same lightweight pipe as "lol 😂". How do you send media?

The call: Upload once to blob storage + CDN; the chat carries a pointer + thumbnail + key. — Media uploads once to blob storage fronted by a CDN near each viewer; the message carries only a small pointer, thumbnail and decryption key, and Bob fetches the blob from the nearest edge. Separate the data plane from the control plane.

Upload media once to blob storage, fronted by a CDN that caches it near each viewer. The chat message carries only a small pointer + thumbnail + decryption key. Bob's phone fetches the blob straight from the nearest CDN edge.

Separate the data plane: Tiny control messages and big media take different roads. Text flows through the fast messaging path; bytes flow through storage + CDN. Mixing them would make both worse.

Step 8 · Trust & scale

2 billion phones, zero peeking

Two hard problems at once: how do a handful of servers hold billions of live connections — and how do you promise that not even WhatsApp can read people's messages?

Connection servers are tuned to hold ~2 million sockets each, so a modest fleet covers the planet; Presence rides the same socket via heartbeats. And every message is end-to-end encrypted — the server only ever relays ciphertext it cannot decrypt.

End-to-end encryption: Keys live only on the devices. The server stores and forwards sealed envelopes — routing them perfectly while being mathematically unable to open them. Privacy by design, not by promise.

You did it

You just designed WhatsApp.

Store-and-forward server — the relay spine between two phones.
Persistent WebSockets so the server pushes messages instantly.
A Session registry routes each message to the right connection server.
Per-user Inbox Queues hold messages for offline recipients.
Acknowledgements drive the ✓ / ✓✓ / blue-tick delivery receipts.
A Group Service fans one message out to every member.
Media via blob storage + CDN; only a tiny pointer rides the chat.
~2M sockets per server and end-to-end encryption at planet scale.

Finished this one? 0 / 65 System Designs done

Explore the topic

See this alongside everything else on the same subject — handbooks, system designs, challenges and tools, in one place.

Real-time & Messaging

The concepts behind this design

The same core ideas underpin every system on this site. Master them once, then spot them everywhere.