Realtime messaging & presence

Design WhatsApp

Medium

Push a message to any of two billion phones the instant it's sent — even the ones that are offline.

WhatsApp is a real-time messaging app: people exchange 1:1 and group messages, see when a contact is online or last seen, and get sent / delivered / read receipts — all end-to-end encrypted.

What makes it a systems problem isn't the message payload; it's the shape of the traffic:

Hundreds of millions of persistent connections. Delivery is server-initiated — the server must push a message the instant it arrives, so every user holds a long-lived socket, not a request/response API.
Reliable delivery regardless of who's online. A message sent to an offline friend must arrive the moment they reconnect, in order, and appear exactly once to the user.

The whole design is about holding tens of millions of sockets per region, knowing which server holds each recipient, and store-and-forwarding every message until it's acknowledged. This is the canonical real-time fan-out at connection scale interview.

Scope it fast. The interviewer wants to see you recognize that this is not a CRUD API: delivery is server-initiated over persistent connections, and every message must be reliably delivered even when the recipient is offline. Those two facts drive every later decision.

Lead with the crux — real-time 1:1 delivery over long-lived sockets plus offline store-and-forward — and keep the functional list tight. Group messaging is a secondary fan-out of the same 1:1 path; media rides a separate blob/CDN path (only a pointer flows through chat); and everything is end-to-end encrypted, so the server routes ciphertext only.

Functional

Send & receive 1:1 messages in real time.Delivered instantly when the recipient is online; end-to-end encrypted — the server routes ciphertext only, never plaintext.
Offline delivery — queue messages for offline recipients and deliver on reconnect, in order.Store-and-forward: nothing is dropped just because a device is asleep.
Delivery + read receipts — sent, delivered, and read state, tracked per recipient and propagated back to the sender.
Group messaging (secondary, up to ~1,000 members) — one send fans out to every member over the same 1:1 delivery path.
Presence — show a contact's online / last-seen status.

Non-functional

Real-time delivery — online-to-online latency < 1 s p99 within a region.
Reliability — at-least-once delivery + client dedup; no message silently lost, even across a server crash.
Connection scale — sustain ~500M concurrent persistent connections at peak.
Throughput — ~2.5M messages/s at peak, plus a comparable volume of receipts.
Availability — 99.99% on the messaging path; losing one gateway must not lose an accepted message.
Ordering — messages within a conversation are delivered in send order.

Out of scope

Voice & video calls
Status / Stories
Media transcoding & storage internals (attachments ride a blob store + CDN; only a pointer flows through chat)
Cryptographic protocol internals (key-ratchet math)
Spam / abuse ML

Check yourself· 3 questions

Question 1

Which property makes WhatsApp fundamentally different from a request/response CRUD app and shapes the whole architecture?

Question 2

Why must the system deliver messages to recipients who are offline at send time?

Question 3

The three receipt states (sent, delivered, read) primarily require what capability?