Design WhatsApp

How to Use This Playbook

This playbook supports three reading modes:

What This Interview Actually Tests

Chat infrastructure is not a "use WebSockets and a database" question. Everyone can build a chat demo.

This is a delivery guarantee and ordering question that tests:

• Whether you separate the connection layer from the message persistence layer
• Whether you reason about message ordering as a per-conversation constraint, not a global constraint
• Whether you understand the fan-out cost difference between 1-to-1 chat and group chat at scale
• Whether you can articulate the operational trade-offs of end-to-end encryption

The key insight: The hardest problem in chat is not sending messages — it is guaranteeing delivery order when the sender, recipient, and network are all unreliable simultaneously. Staff engineers design for the failure case first, then optimize the happy path.

The L5 vs L6 Contrast (Memorize This)

The Three Messaging Intents (Pick One and Commit)

The Four Fault Lines (Preview)

1. Delivery Guarantee — At-most-once (fast, lossy) vs at-least-once with dedup (reliable, complex). Who absorbs duplicate handling?
2. Message Ordering — Total order (expensive, doesn't scale) vs per-conversation order (practical) vs causal order (for replies and threads). What breaks when ordering is relaxed?
3. Group Fan-Out — Write-time fan-out (fast reads, expensive writes) vs read-time fan-out (cheap writes, slow reads). The 256-member threshold where everything changes.
4. Presence Accuracy — Real-time heartbeat (accurate, expensive) vs lazy presence (cheap, stale). Whether "last seen" is a feature or a liability.

Quick Reference: What Interviewers Probe

Jump to Practice

-> Active Drills (§7) -- 8 practice prompts with expected answer shapes

System Architecture Overview

Interview Walkthrough: How to Present This in 45 Minutes

Most interview prep covers the basics — step-by-step architecture walkthroughs at tutorial pace. This section is different. Senior candidates spend 25 minutes on the basics and run out of time before reaching anything interesting. Staff candidates speed through the baseline in 10-12 minutes — fast enough to spend the remaining 30+ minutes on the fault lines, failure modes, and ownership questions that actually determine your level.

The six phases below add up to 45 minutes. The ratios matter: phases 1-4 are deliberately compressed so phase 5 gets the lion's share of time. If you're spending more than 12 minutes before the transition to depth, you're pacing like an L5.

Phase 1: Requirements & Framing (2-3 minutes)

State functional requirements in 30 seconds — don't enumerate, state the category:

• "Users send and receive messages in 1-to-1 and group conversations. Messages persist across devices, sync offline, and support media attachments, delivery receipts, and typing indicators."

That's it. Don't list every feature. The interviewer knows what chat does.

Invest time on non-functional requirements (this is the Staff move):

• "The hard constraint is the delivery guarantee: at-least-once with client-side dedup. We can never lose a message, but we can tolerate brief duplicates."
• Clarify: per-conversation ordering with server-assigned sequence numbers
• "End-to-end encryption for consumer chat — the server never sees plaintext. Online delivery under 200ms; offline queue with configurable TTL."

Phase 2: Core Entities & API (1-2 minutes)

State entities quickly (30 seconds):

• Conversation: participant list, per-conversation sequence counter, metadata
• Message: sender, content (encrypted blob), sequence number, delivery status
• Connection: WebSocket session tied to a specific gateway server, authenticated
• Inbox: per-device offline queue holding undelivered messages

API (1 minute) — the key interaction is send-with-acknowledgment:

WS SEND  { conversation_id, content, client_msg_id } → server ACK { sequence_num }
WS RECV  { conversation_id, message, sequence_num }   → client ACK { sequence_num }
GET /conversations/{id}/messages?after_seq={n}         → missed message backfill

Phase 3: High-Level Architecture (5-7 minutes)

Walk through the flow:

1. Send → Client sends message over WebSocket to Connection Gateway; gateway forwards to Message Router
2. Persist + sequence → Router writes to Message Store, assigns per-conversation sequence number, ACKs sender
3. Route → Router publishes to Pub/Sub; recipient's gateway pushes to recipient if online
4. Offline → If recipient is offline, message queued in Inbox; delivered on reconnect with sequence-based backfill

Key points to hit on the whiteboard:

1. Connection Gateway — stateful WebSocket servers with Redis-backed connection registry for routing
2. Message Router — the decision point: persist first (durability), then route (availability)
3. Inbox Queue — not an afterthought; offline delivery is the common case for global chat
4. Pub/Sub — Redis Pub/Sub or Kafka depending on scale; decouples send from deliver

Phase 4: Transition to Depth (1 minute)

At this point you've spent ~12 minutes. Now pivot:

"The basic architecture is straightforward — gateway, router, message store. What makes this a Staff-level problem is the failure mode reasoning. Let me dive into three areas: (1) delivery guarantees when the sender's connection drops mid-send and the recipient is on another continent, (2) group fan-out economics at scale — write amplification vs read amplification, (3) E2E encryption key management when a group member is removed."

Then offer the interviewer a choice:

"I can go deep on any of these. Which is most interesting to you?"

If the interviewer doesn't have a preference, lead with delivery guarantees — it's the most impressive and the most universally applicable.

Phase 5: Deep Dives (25-30 minutes)

The interviewer will steer, but be prepared to go deep on any of these. For each, follow the Staff pattern: state the tradeoff → pick a position → quantify the cost → explain who absorbs that cost.

Fault Line 1: Delivery guarantees under failure (7-10 min)

Open with the tradeoff framing:

"The hard case isn't 'Alice sends Bob a message.' The hard case is: Alice hits send, her connection drops before she receives the server ACK, and Bob is offline on another continent. What happened? Did the server receive it? Did it persist? Is it sitting in Bob's inbox or was it lost?"

Walk through the bidirectional ACK protocol:

1. Client sends message with client_msg_id (UUID generated locally)
2. Server persists message → assigns sequence_num → ACKs to sender with { client_msg_id, sequence_num }
3. If the sender doesn't receive the ACK → client retries on reconnect with the SAME client_msg_id
4. Server deduplicates on client_msg_id → returns existing sequence_num (idempotent)
5. Recipient's client ACKs delivery → server marks delivered; if no ACK → stays in Inbox for redelivery

The key insight: "The client_msg_id makes retries idempotent. The server ACK tells the sender 'I have it.' The client ACK tells the server 'they received it.' Without both sides, you have a gap."

Then go deeper on ordering: "Per-conversation sequence numbers give total order within a conversation. But for replies and threads, we also need causal ordering — a reply must never appear before the message it references. We handle this with a reply_to_seq field and client-side buffering: if a reply arrives before its parent, the client buffers it until the parent arrives."

Fault Line 2: Group fan-out economics (5-7 min)

Frame with concrete numbers:

"A 100-person group where every message is fan-out-on-write means 100 inbox writes per message. If the group sends 200 messages/day, that's 20,000 write operations daily per group. At 10,000 active groups, that's 200 million write operations/day just for inbox fan-out."

Present the tradeoff:

• Write amplification (fan-out-on-write): Write to every recipient's inbox at send time. Read is simple — each user reads their own inbox. Cost: O(N) writes per message.
• Read amplification (fan-out-on-read): Write once to the conversation store. Each read pulls from the shared store and filters. Cost: O(1) write, but every read hits the shared store.

Pick a position: "I'd use fan-out-on-write for groups under 500 members and fan-out-on-read for large groups like broadcast channels. The threshold is where write amplification exceeds the read query cost — for groups with a 10:1 read-to-message ratio, that's roughly 500 members."

Then address the hot group problem: "A viral group where 500 members are all typing creates a thundering herd on the fan-out pipeline. Mitigation: batch fan-out with micro-batching (100ms windows), and separate the typing indicator pipeline from the message pipeline entirely — typing indicators are fire-and-forget, messages are durable."

Fault Line 3: E2E encryption key management (5-7 min)

"End-to-end encryption sounds simple: encrypt with a shared key, only group members can decrypt. The hard part is key rotation — what happens when someone leaves a group?"

Walk through the Signal Protocol Double Ratchet approach:

1. Group key: A symmetric key shared among all group members, used to encrypt messages
2. Member removal → ALL remaining members must receive a NEW group key. The departing member still has the old key (forward secrecy requires key rotation)
3. Key rotation storm: In a 100-person group, removing one member triggers 99 key distribution messages. Remove 5 members and you've sent 495 key messages before a single chat message
4. Multi-device: Each user may have 3+ devices, each needing its own key exchange. 100 members × 3 devices = 300 key distribution events per rotation

The architectural implication: "Key management traffic can exceed actual message traffic. We need a separate key management channel with its own queue and delivery guarantees. Key distribution is 'at-least-once with dedup' — a missed key update means a member can't decrypt future messages until they re-request."

Message ordering across regions (3-5 min)

"In a global system with servers in US, EU, and APAC, two members of the same conversation may be connected to different regions. Server-assigned sequence numbers require a single sequencer per conversation, which means cross-region round trips. The options: (1) pin each conversation to a home region and accept higher latency for remote members, (2) use logical clocks (Lamport or vector clocks) for partial ordering, or (3) use a globally consistent ID generator like Snowflake with timestamp-based ordering."

Pick a position: "I'd pin conversations to a home region (where the creator is located) and use async replication. Remote members see ~100-200ms additional latency, which is imperceptible in chat. The alternative — distributed consensus per message — adds 200-400ms for everyone."

Phase 6: Wrap-Up (2-3 minutes)

Summarize the key insight — don't just restate your architecture:

"Chat messaging is deceptively simple. Every engineer has built a toy chat app with WebSocket and a database. What makes it Staff-level is three things: (1) the delivery guarantee contract — at-least-once with bidirectional ACKs makes the failure modes tractable, (2) the fan-out economics — write amplification forces an architectural boundary at ~500 members, and (3) encryption isn't a feature you bolt on — the key management infrastructure can be larger than the messaging infrastructure."

If time permits, add the organizational insight:

"The hardest operational problem isn't message delivery — it's abuse. Who decides what constitutes spam? Who reviews reports? Who handles government takedown requests for E2E encrypted content? These are organizational design problems that shape the technical architecture."

Common Timing Mistakes

Reading the Interviewer

What to Deliberately Skip