WhatsApp System Design: The Problem

Send a message to a friend and it arrives in under a second, even if they're on a 2G connection in another country. When it arrives you see two grey ticks. When they read it, the ticks turn blue.

Doing that for over two billion users is one of the classic system design problems, and WhatsApp's real architecture is famous for how small the team behind it was.

This guide walks through how a WhatsApp-style messenger works, using what WhatsApp and Meta have said publicly, and the trade-offs you'd discuss in a system design interview.

🎯 Quick Answer (30-Second Read)

  • Persistent connection: each phone keeps one long-lived connection to WhatsApp's servers, so messages can be pushed instantly.
  • Store and forward: if the receiver is offline, the server stores the message and delivers it when they reconnect, then deletes it.
  • Erlang: WhatsApp's backend famously ran on Erlang, built for huge numbers of lightweight concurrent processes.
  • Ticks are receipts: ✓ = server received it, ✓✓ = delivered to the phone, blue ✓✓ = read.
  • End-to-end encryption: since 2016, messages use the Signal Protocol, so servers relay ciphertext they can't read.

WhatsApp in Numbers

2B+
users (WhatsApp, 2020)
100B+
messages a day (Meta, 2020)
$19B
Facebook acquisition (2014)

When Facebook bought WhatsApp in 2014, it had over 450 million monthly users and a famously tiny engineering team, often cited as around 32 engineers.

Requirements (Interview Framing)

Functional: 1-to-1 chat, group chat, delivery and read receipts, online/last-seen, media (photos, video, voice notes), offline delivery.

Non-functional: very low latency, high availability, messages delivered in order and exactly once from the user's view, works on weak mobile networks, end-to-end encrypted.

High-Level Architecture

WhatsApp hasn't published a full internal diagram, so this is the standard design for a WhatsApp-style messenger, built from what its engineers have shared publicly (persistent connections, store-and-forward, separate media handling, Signal-protocol keys).

flowchart TB A["📱 Alice's phone"] <-->|persistent connection| LB["Load balancer"] B["📱 Bob's phone"] <-->|persistent connection| LB LB <--> CS1["Chat server 1"] LB <--> CS2["Chat server 2"] CS1 <--> SR[("Session registry
which user is on which server")] CS2 <--> SR CS1 <--> Q[("Offline message queue")] CS1 <--> G["Group service
fan-out to members"] CS1 --> P["Push notifications
(APNs / FCM)"] A -->|encrypted upload| M[("Media storage")] M -->|encrypted download| B A <-->|public keys| K[("Key server")] PR["Presence service
(in memory)"] <--> CS1
Component Job
Chat servers Hold millions of open connections and pass messages along
Session registry Knows which chat server each online user is connected to, so a message can be routed to the right one
Offline queue Holds messages for offline users, deleted once delivered
Push notifications Wakes an offline phone through Apple or Google so it reconnects
Media storage Stores encrypted photos and videos, outside the chat path
Key server Hands out public keys so phones can start encrypted chats
Presence service Tracks online / last seen, kept in memory

Routing a message from Alice to Bob: Alice's chat server looks up Bob in the session registry. If Bob is connected to chat server 2, the message is forwarded there and pushed down Bob's connection. If Bob isn't connected anywhere, it goes to the offline queue and a push notification wakes his phone.

How a Message Is Delivered

sequenceDiagram participant A as Alice (phone) participant S as Chat server participant B as Bob (phone) A->>S: Encrypted message (over persistent connection) S-->>A: Ack → one grey tick ✓ alt Bob is online S->>B: Push message B-->>S: Delivered receipt S-->>A: ✓✓ delivered else Bob is offline S->>S: Store until Bob reconnects B->>S: Reconnects S->>B: Deliver stored messages B-->>S: Delivered receipt S-->>A: ✓✓ delivered end B-->>A: Read receipt (via server) → blue ✓✓

1. Persistent connections

Instead of the phone asking "any new messages?" every few seconds (polling), each phone keeps one open connection to a chat server. The server pushes messages the instant they arrive. This saves battery and data, and makes delivery near-instant.

The hard part is the sheer number of open connections. In 2012, WhatsApp's own engineering blog described pushing a single server past 2 million simultaneous connections.

2. Erlang: built for millions of tiny processes

WhatsApp's backend was famously built in Erlang, a language from the telecom world. Erlang runs huge numbers of extremely lightweight processes (roughly one per connected user), restarts crashed parts automatically, and lets engineers update code without taking servers down. Those properties suit a messaging system perfectly. WhatsApp engineers presented this setup, running on FreeBSD, at Erlang conferences.

3. Store and forward

If Bob is offline, the server queues the message and delivers it when Bob reconnects. Once delivered, it's removed from the server. Messages aren't kept on WhatsApp's servers long term, so the main history lives on users' devices (and their backups).

4. Receipts: the ticks

Tick Meaning
✓ (grey) The server received the message
✓✓ (grey) Delivered to the recipient's phone
✓✓ (blue) The recipient opened the chat

Each tick is just a small acknowledgement message travelling back through the server.

5. Ordering and duplicates

Weak networks mean retries, and retries can mean duplicates. Each message gets a unique ID. The receiver ignores IDs it has already seen, and per-chat sequence handling keeps messages in order. That's how users see each message exactly once.

Group Chats

When Alice sends to a group, the server fans out a copy to every member's connection or offline queue. Bigger groups mean more fan-out work per message, which is one reason group sizes are capped.

With end-to-end encryption, groups use sender keys: Alice encrypts the message once with a group key that members already have, so she doesn't have to encrypt it separately for every member.

Media: Photos, Videos, Voice Notes

Big files don't travel through the chat connection:

  1. The sender's app encrypts the file and uploads it to media storage.
  2. The chat message carries only a pointer plus the decryption key (inside the end-to-end encrypted message).
  3. The receiver downloads the encrypted file and decrypts it locally.

That keeps the real-time chat path light and fast.

End-to-End Encryption

Since 2016, WhatsApp has used the Signal Protocol for all messages. Keys live on users' devices, so the server relays ciphertext it can't read. Each device publishes public keys to the server, and senders use them to set up encrypted sessions.

Watch out (interview tip): encryption limits what the server can do. Server-side search, spam scanning of message content and cloud history are all much harder. That's a real design trade-off worth mentioning.

Online Status and "Last Seen"

Presence is a constant stream of tiny updates, so systems keep it in memory and only share it with contacts who are allowed to see it. Exact accuracy isn't critical. A few seconds of delay is acceptable, which makes it far cheaper than message delivery.

Lessons From WhatsApp's Design

  • Pick tools that fit the problem. Erlang's concurrency model matched millions of long-lived connections.
  • Keep the server simple. Store, forward, delete. Don't become an archive.
  • Do the heavy work at the edges. Encryption and media processing happen on devices.
  • A small team can run huge systems when the architecture avoids unnecessary moving parts. Read more: How WhatsApp Served 450 Million Users With a Tiny Team.

Frequently Asked Questions

What language is WhatsApp's backend written in?

WhatsApp's backend was famously built in Erlang, running on FreeBSD, as its engineers described in conference talks. Erlang's lightweight processes and fault tolerance suit systems with millions of simultaneous connections. Since joining Meta, WhatsApp has also used Meta's wider infrastructure.

Does WhatsApp store my messages on its servers?

Messages are stored on WhatsApp's servers only until they're delivered (or for a limited time if the recipient stays offline), and they are end-to-end encrypted. Your chat history lives on your device and in any backups you enable, which you can also encrypt.

How would you design WhatsApp in a system design interview?

Cover persistent connections (WebSockets or similar), a chat service that routes messages to the recipient's connection, an offline queue for store-and-forward, unique message IDs for deduplication, receipts for ticks, fan-out for groups, separate media storage, presence in memory, and end-to-end encryption, plus the trade-offs each choice brings.

Conclusion

WhatsApp's design comes down to a few strong ideas: one persistent connection per phone, a server that stores and forwards rather than archives, receipts for every step, media sent separately, and encryption done on the device. Simple pieces, executed at enormous scale.

Sources

Last verified: 14 October 2026.

Related reads: How WhatsApp Served 450 Million Users With 3 Engineers · Load Balancer Explained · How Discord Scaled · How Twitter's Architecture Handles 500 Million Tweets

I write about system design and how real products are built. Follow on LinkedIn or X, or invite me to speak.