System Design Arena
Design WhatsApp
A real-time chat system: 1:1 and group messaging, delivery/read receipts, offline delivery, and end-to-end encryption — at two billion users.
Case Study
Same conversation, diagrams, and wrap-up you expect—now framed with clearer scaffolding and iconography.
Prompt
Design a messaging service like WhatsApp supporting 1:1 chats, group chats, delivery and read receipts, and message delivery to devices that were offline.
Interview snapshot
- • Topic: WhatsApp
- • Expected depth: 45 - 60 minutes
- • Focus areas: APIs, scale estimation, resilient architecture
- • Wrap-up: risk, monitoring, disaster recovery
Key takeaways
- • 1:1 and group messaging with at-least-once delivery and per-conversation ordering.
- • Message latency under ~200ms sender-to-recipient when both online.
- • Persistent WebSocket per device; frames: send(convId, clientMsgId, ciphertext), ack(msgId), receipt(msgId, state).
🎙️ Interview mode
Practice this like a real interview
Don't read the answer first. Work the framework against the bare prompt, then compare against what the interviewer expected at each step.
Scorecard
What the interviewer is evaluating
Staff-level signal
Does the candidate design around persistent connections and say "durability before delivery" — persisting to the inbox before ACKing — unprompted?
🧠 Staff engineer judgment
Messages are 1KB. This is never a bandwidth problem — do not design a CDN for text. The scarce resources are connections and fan-out.
Calibration
The common (bad) answer
Sender → API → DB Recipient polls GET /messages every 2s
❌ Why this scores poorly: Polling at 2B users is 1B QPS of mostly-empty responses, and messages feel slow. Real chat is push over persistent connections with server-side inboxes.
✓ What a strong answer adds
- Persistent WebSocket per device + a connection registry for routing.
- Persist to the recipient inbox BEFORE acking the sender — no lost messages.
- Per-conversation sequence numbers from a single-writer partition for ordering.
- Offline devices drain their inbox by cursor on reconnect.
- Group fan-out as an explicit service with a size cap.
Video walkthrough
WhatsApp System Design: chat messaging systems
Gaurav Sen · 25 min
The classic messaging walkthrough: connection handling, delivery receipts and offline queues.
Work the prompt yourself first — guided practice grades your own answer step by step. Watching someone else design it feels like progress and teaches you far less.
Interview flow
Dialogue timeline
Interviewer
What must this system do at its core?
Candidate
Send and receive messages in 1:1 and group chats with at-least-once delivery, show sent/delivered/read states, and deliver messages that arrived while a device was offline. Media sharing rides on top; calls are out of scope today.
Interviewer
What scale are we designing for?
Candidate
Say 2B users, 100B messages/day — about 1.2M messages/sec average, several times that at peak. Messages are small (~1KB), so this is a connection-and-fanout problem, not a storage-bandwidth problem.
Interviewer
How do clients connect?
Candidate
Persistent connections — WebSocket or raw TCP like WhatsApp's modified XMPP. Each device holds one connection to a chat server; a connection registry maps user→server so anyone can route a message to the right box.
Interviewer
Walk me through sending a 1:1 message.
Candidate
Sender pushes the message over its connection. The chat server persists it to the recipient's inbox queue first — durability before delivery — then looks up the recipient's connection and pushes it. Recipient ACKs; we mark delivered and notify the sender. If offline, it waits in the inbox and a push notification nudges the device.
Interviewer
Group chat with 200 members — how does fan-out work?
Candidate
The sender writes once to a group inbox; a fan-out service expands membership and writes to each member's inbox. Small groups fan out on write. We cap group size precisely because fan-out cost is linear — WhatsApp's own cap exists for this reason.
Interviewer
Where does message ordering come from?
Candidate
Per-conversation sequence numbers assigned by the inbox partition that owns the conversation — a single writer per conversation makes ordering trivial. Cross-conversation ordering doesn't matter.
Interviewer
A device was offline for a week. What happens on reconnect?
Candidate
It sends its last-seen sequence per conversation; the server replays everything after that from the inbox store, then resumes streaming. Inbox retention is bounded — media is fetched separately from blob storage by reference.
Interviewer
How does end-to-end encryption change the server design?
Candidate
Servers route ciphertext they can't read — Signal-protocol keys live on devices. That kills server-side search and content features, and multi-device needs per-device sessions. It's a product trade-off: privacy over server-side intelligence.
Scoping
Requirements & trade-offs
Functional Requirements
- —1:1 and group messaging with at-least-once delivery and per-conversation ordering.
- —Delivery states: sent (server has it), delivered (device has it), read (user saw it).
- —Offline delivery: messages queue server-side and replay on reconnect.
- —Out of scope for 45 min: voice/video calls, stories, payments.
Non-Functional Requirements
- —Message latency under ~200ms sender-to-recipient when both online.
- —No message loss, ever — durability before delivery ACK.
- —2B users with tens of millions of concurrent connections per region.
- —End-to-end encrypted: the server never sees plaintext.
Blueprint
Architecture modules
Module 1
API & Protocol
- •Persistent WebSocket per device; frames: send(convId, clientMsgId, ciphertext), ack(msgId), receipt(msgId, state).
- •clientMsgId makes sends idempotent across retries.
- •HTTP APIs for media upload (returns blob ref sent in the message) and history sync.
- •Push notification hook (APNs/FCM) for offline nudges — content-free because of E2EE.
Module 2
Back-of-the-Envelope
- •100B msgs/day ≈ 1.2M/sec average, ~4M/sec peak.
- •1KB average message → ~100TB/day of message traffic; retention dominated by media, not text.
- •20M concurrent connections per large region → ~200 chat servers at 100K connections each.
- •Connection registry: 2B entries of user→server, trivially cacheable.
Module 3
System Diagram Notes
- •Device → LB (sticky) → Chat Server ↔ Connection Registry (Redis).
- •Chat Server → Inbox Store (partitioned by conversation, single writer per partition).
- •Fan-out service between group inbox and member inboxes.
- •Media path is separate: device → blob store → reference travels in the message.
Module 4
Design Playbook
- •Lead with the connection layer — it is the defining constraint of chat systems.
- •Say 'durability before delivery' explicitly; it is the sentence interviewers wait for.
- •Justify per-conversation single-writer ordering before anyone asks about clocks.
- •Treat group fan-out as the scaling cliff and name the cap.
- •Close with what E2EE costs the backend: no server-side search, per-device sessions.