Design WhatsApp / Chat Messaging

00Quick Orientation

Chat looks like one problem from the outside but decomposes into several distinct sub-problems once you start designing it. Persistent connections drive the architecture. Delivery semantics drive the reliability story. Group chat is its own fan-out problem. Presence has its own scaling characteristics. Each of these is a depth probe; strong walkthroughs treat them as separate beats rather than blending them into one continuous discussion.

The four framework steps from the methodology page structure the walkthrough:

1. Clarify (5 min) — Scope, scale, edge cases. One-on-one only, or also groups? Encryption? What's the latency target?
2. Decompose (10 min) — High-level architecture. Where do persistent connections live, how does a message flow from sender to recipient.
3. Deep-dive (25-30 min) — Message delivery semantics, group fan-out, brief notes on presence and end-to-end encryption.
4. Evaluate (5 min) — Failure modes, what we'd add at the next scale, where the design would break.

Step 1Clarify (5 min)

Chat has a wide scope by default. The clarification step narrows the scope and surfaces assumptions that will drive every later decision.

The conversation

Functional requirements

• Send / receive messages. Text only for the core design.
• One-on-one chat. Two users exchanging messages.
• Group chat. Multiple users (capped at a few hundred members) sharing a conversation.
• Presence. Online / offline / last-seen indicators.
• Read receipts. Sender sees when recipient has read the message.
• Message persistence. Full conversation history, retrievable.
• Push notifications. Wake up offline clients when messages arrive.
• End-to-end encryption. Server can route but not read message content.

Non-functional requirements

• Scale. Two billion users, one billion DAU.
• Latency. Sub-second p99 message delivery for online recipients.
• Reliability. No lost messages. At-least-once delivery is acceptable; client deduplicates.
• Availability. Highly available. Brief degradation acceptable; permanent message loss not.
• Mobile-friendly. Intermittent connectivity, low data usage, battery-conscious.

Quick scale estimation

Three things this tells us. First, the message rate (3M/sec peak) is high but not exotic. Second, the concurrent connection count (300M) is the hard number — keeping persistent connections to hundreds of millions of clients is what distinguishes chat from request-response systems. Third, storage at 6 PB/year compounds — we need to think about retention and tiering.

The connection number is also what makes the gateway tier the load-bearing layer. A typical server handles ~50K-100K WebSocket connections; 300M concurrent connections means several thousand gateway servers, geographically distributed.

Step 2Decompose (10 min)

The high-level architecture. The defining feature: persistent connections from clients to the gateway tier, which is what enables real-time push from server to client without polling.

Walking through the components

• Clients (sender / recipient). Mobile or web. Maintain a persistent WebSocket connection to a gateway server. The connection stays open as long as the client is online; messages can be pushed in either direction without polling.
• Gateway tier. Terminates client connections. Each gateway server holds tens of thousands of open WebSocket connections. The gateway translates between the client wire protocol and internal message events. It's also the hardest tier to operate because of stateful long-lived connections — see the rate limiting deep-dive on the connection-stickiness problem.
• Message Service. The central authority. Validates the message, generates a server-assigned message ID and timestamp, persists the message to the store, publishes a routing event to the queue. Returns ACK to the sender's gateway, which forwards it to the sender client.
• Message Store. The system of record. Sharded by conversation ID (one-on-one or group). Cassandra, DynamoDB, or similar — the workload is append-heavy with point lookups, exactly what these stores are good at. Database selection and sharding cover the underlying patterns.
• Routing Queue. Kafka or equivalent. Decouples the sender's write from the recipient's delivery. Each message published once; downstream Delivery Workers consume.
• Delivery Workers. Consume from the routing queue. For each recipient, look up whether they're online (presence service) and which gateway holds their connection. If online: route the message event to that gateway. If offline: hand off to the push service.
• Push Service. Talks to APNs (Apple) and FCM (Google) to send notifications to mobile devices that don't have an active connection. This is the "you have a new message" notification on the lock screen.

Why the persistent connection is load-bearing

The most important architectural fact in chat: clients hold persistent connections, not request-response sessions. This single decision drives several downstream concerns:

• Stateful gateways. Gateway servers are not stateless; each one tracks which users' connections it holds. Load balancing is not just round-robin; the recipient's gateway location must be discoverable.
• Connection scaling. Each gateway handles ~50K-100K open connections. 300M concurrent users means thousands of gateway servers. Operationally non-trivial.
• Failure handling. If a gateway crashes, all of its connections drop. Clients reconnect (often to a different gateway), and the system must catch up on undelivered messages.
• Geographic distribution. Gateways are deployed regionally; clients connect to the nearest one. The Message Service stays mostly central but sees regional traffic.

Many candidates skip this architectural commitment and end up with a polling-based design that doesn't meet the latency target. Naming the persistent connection explicitly is what distinguishes a chat design from a generic request-response design.

Step 3aDeep-Dive: Delivery Semantics (12 min)

The single most-probed depth question in chat interviews: how do you guarantee message delivery? This is where many candidates fall apart by promising exactly-once or by handwaving "we'll just use a queue." The right answer is at-least-once delivery with idempotent client handling and an explicit message lifecycle.

The delivery semantics choice

Three options, only two are practical, and only one is the canonical answer.

The message lifecycle

A message moves through three states as it traverses the system. Each transition involves an explicit acknowledgement that flows back to the sender, which is what powers the WhatsApp-style checkmark UI ("sent" / "delivered" / "read").

Walking through each stage

SENT: client → server, server persists

Client sends the message with a client-side ID (typically a UUID or monotonic counter). The server receives it, generates a server-assigned message ID, persists to the message store, and returns ACK with the server ID. Until the client receives this ACK, the message shows "sending..." in the UI. After ACK, it shows the single check ("sent").

The retry behavior here matters: if the client doesn't receive ACK within a timeout (a few seconds), it retries with the same client_id. The server uses the client_id for idempotency — if it's already seen this client_id, return the same server_id rather than creating a duplicate.

DELIVERED: server → recipient, recipient ACKs

The Delivery Worker (consuming from the routing queue) checks recipient presence. If online, the worker hands the message event to the recipient's gateway, which pushes over the open WebSocket. The recipient's client receives, persists locally, and sends a delivery ACK back. The ACK flows server-side back to the sender's session, which updates the sender's UI to two checks ("delivered").

If the recipient is offline, this stage is delayed. The message sits in the recipient's pending queue (or is fetched on next reconnect). The push notification fires concurrently to wake the device.

READ: recipient opens chat, sends read receipt

When the recipient actually opens the conversation and sees the message, the client sends a read receipt. Server forwards to sender, sender's UI updates to two blue checks ("read"). This stage is only relevant if read receipts are enabled; some users disable them for privacy.

Idempotency: making at-least-once safe

At-least-once means duplicates can happen. The client must handle them safely. Two common dedupe strategies:

• Server-assigned IDs. The server stamps each message with a unique server_id. When the client receives a message, it checks against locally-stored recent IDs. If already seen, drop the duplicate silently.
• Client-assigned IDs. The client_id (sent with the message originally) is also used for dedupe. Useful for sender-side: if the network glitches and the client retries the send, the server uses client_id to avoid creating two copies.

Most production systems use both: server_id for downstream deduplication, client_id for retry safety on the sending side. The cost is small (a few-hundred-ID rolling buffer per client) and the reliability gain is large.

Ordering

The other delivery question: what order do messages appear in the conversation? Two layers of ordering:

• Within a conversation, server timestamps order messages. The server stamps each message at receipt time; messages are stored in timestamp order per conversation. Client UIs sort by this timestamp.
• Across conversations (the user's chat list), last-message-time orders. The recent-conversations view sorts by the most recent message in each conversation.

Clock skew between users is a non-issue because the server is the single source of timestamps. Clock skew between server replicas can cause minor reordering at the boundary, which is usually acceptable; if strict ordering is required (rare in chat), use sequencers per conversation rather than wall clocks.

At-least-once is the answer. Exactly-once is a trap. Idempotent clients turn duplicate handling into a non-event.

Step 3bDeep-Dive: Group Chat Fan-Out (8 min)

Group chat looks like one-on-one chat but it isn't. The architectural decisions diverge at the moment of "send a message to a group of N people." Strong walkthroughs treat group chat as its own sub-problem rather than handwaving it as the same plus more.

The choice: store-once or store-per-recipient?

Two ways to think about a group message: as one logical message that belongs to a conversation, or as N copies (one for each recipient).

• Store-once-per-conversation. The message is persisted once in the conversation's storage. Each member's view of the conversation reads from the same shared log. Storage is cheap.
• Store-per-recipient. The message is copied N times, once per recipient member. Each member has their own message log. Storage is N times more expensive but per-recipient state (delivery, read) is simpler.

The right answer for a chat platform with capped group sizes is store-once-per-conversation, plus per-recipient delivery state tracked separately. We don't pay N-times storage; we do pay the small overhead of tracking delivery/read state per member.

The fan-out itself

Once persisted, the message must reach every member. The fan-out is similar to the social feed pattern but smaller in scale (a few hundred members vs millions of followers).

Per-recipient delivery state

Each member tracks their own delivery state for the message: not-yet-delivered, delivered, read. Storing per-recipient state separately from the message itself keeps the storage layout clean: one row in the message table (the message), N rows in a delivery state table (one per recipient member).

For groups of a few hundred members, this is bounded and cheap. For broadcast channels (millions of subscribers), this would explode — which is why we limited group size to a few hundred during clarification. Broadcast channels are a different pattern with different decisions.

The depth-probe response

"What about read receipts in a group?" The strong response: "Each member has their own read state. The sender's UI typically shows aggregated state — 'read by 5 of 10' — rather than tracking each individual. We'd compute the aggregation when the sender opens the message details, not push it to them in real time. Real-time per-recipient read tracking would multiply the read-receipt traffic by the group size; not worth the cost."

Step 3cDeep-Dive: Presence, Read Receipts, Encryption (5 min)

Three sub-problems that show up in nearly every chat interview as depth probes. Each one is its own design decision; naming the canonical answer is enough to demonstrate awareness without burning interview time on full deep-dives.

Presence: heartbeats with eventual consistency

Presence (online / offline / last-seen) sounds simple but has subtle scaling problems. Naive presence (every status change is broadcast immediately to every interested party) creates massive write amplification: when a popular user comes online, hundreds of conversations need to know.

The canonical approach:

• Clients heartbeat to their gateway every ~30 seconds. The gateway forwards the heartbeat to a presence service, which updates the user's last-seen timestamp.
• Presence is eventually consistent. A user's status might be a few seconds stale. That's fine for chat; nobody's billing decisions depend on chat presence.
• Subscribers pull rather than get pushed. When a client opens a conversation, it queries the presence of the participants. The query is cheap; pushing every status change to every interested client would not be.
• Typing indicators are ephemeral. They don't persist. The typing-start event flows over the same WebSocket, broadcast to participants, expires in a few seconds.

The key insight: presence is high-volume but low-value-per-update. Optimize for cheap reads (pull on demand) rather than expensive pushes (every status change broadcast).

Read receipts: optional per-message acknowledgements

The READ stage in the message lifecycle. When the user actually opens the conversation, the client sends a "read up to message_id X" signal. Server marks all messages in the conversation up to that ID as read for this user, forwards to the sender's session.

For groups, the per-recipient read state is stored per (message_id, recipient_id) tuple. Aggregation ("3 of 5 read") happens at query time, not at write time.

Read receipts are user-toggleable in production systems. When disabled by either side, the receipt is suppressed end-to-end. The sender's UI shows "delivered" only, not "read."

End-to-end encryption: the server can't read

E2EE changes what the server can see. Three layers of impact:

• Message content is encrypted client-to-client. The server stores ciphertext, routes ciphertext, never sees plaintext. Keys are negotiated client-side via Signal protocol or similar (X3DH for initial key exchange, Double Ratchet for forward secrecy).
• Server can still see metadata. Who sent to whom, when, message size. The conversation graph is visible even when content isn't. This is a real privacy limitation; users sometimes assume E2EE means nothing is visible, which isn't true.
• Some features become impossible. Server-side message search can't work over encrypted content. Server-side spam filtering can only use metadata. Cross-device sync requires careful key management. These tradeoffs are real and should be acknowledged.

For groups, E2EE is more complex: each member has their own keys, so the message must be encrypted N times (once per member) or use a group key shared via secure channels. WhatsApp uses the second approach (sender keys); Signal uses pairwise. Both work; pairwise is more secure but more expensive.

The interview move on E2EE: name the canonical pattern (Signal protocol or pairwise / sender keys for groups) and acknowledge the tradeoffs (no server-side search, metadata still visible). Don't try to walk through the cryptography in detail unless the interviewer specifically asks; that's a different interview.

Step 4Evaluate (5 min)

The closing move. What we built, what we skipped, what would break under stress, what we'd add at the next scale.

What we got right

• Persistent connections named explicitly. The gateway tier with WebSocket termination is the architectural primitive. Without naming this, the design defaults to polling and misses the latency target.
• At-least-once delivery with idempotent clients. The canonical pattern. Avoids the exactly-once trap; pairs reliable retry with safe deduplication.
• Group chat as its own sub-problem. Fan-out to members, per-recipient delivery state, store-once-in-conversation. Recognized as distinct from one-on-one chat rather than blended.
• Three-stage message lifecycle (SENT, DELIVERED, READ). Mirrors what users see in WhatsApp / iMessage / similar; explicit ACKs at each stage.

What we'd add at the next scale

• Geographic distribution of gateways. 300M concurrent connections demand regional gateway pools. Connect users to the nearest gateway; route the routing queue regionally where possible. Replication and consistency covers the cross-region tradeoffs.
• Multi-device sync. WhatsApp now supports up to four linked devices per account; each must see the same conversation state. Adds state synchronization complexity (when a new device joins, it needs the recent message history; when one device reads, the others should reflect it).
• Tiered storage for old messages. Most queries hit recent messages. Old messages (months or years old) are rarely read. Move them to colder, cheaper storage tiers; keep recent messages in fast storage. Database selection covers the tier choices.

What we explicitly didn't cover

• Voice and video calls (whole separate signaling and media architecture, WebRTC).
• Media messages (images, videos, files) — separate object store, transcoding, link previews.
• Status updates and stories (more like a social feed pattern).
• Backups, archives, message export.
• Spam filtering and abuse detection (especially hard with E2EE).
• Account migration, phone number changes, device replacements.

Where this design would break

• Mass connection drops (gateway crash). A single gateway crash drops 50K-100K connections. Clients reconnect (often to different gateways), and the system must catch up on undelivered messages quickly. Mitigation: persistent client state (last-seen message ID per conversation), efficient reconnect-and-fetch paths.
• Routing queue backlog. If Delivery Workers fall behind during a traffic spike, message delivery latency spikes. The 1-second target is missed; users see noticeable delay. Mitigation: provisioned for peak, autoscale workers, separate queues per priority tier (interactive vs background).
• Presence storms. When network conditions cause many users to disconnect simultaneously (bad WiFi, mobile dead zones), the presence service sees a write storm. Mitigation: rate limit presence updates per gateway, batch updates, accept brief inconsistency.
• Push notification rate limits. APNs and FCM have per-app rate limits. A message storm to many offline users could hit those limits. Mitigation: prioritize, batch where possible, accept best-effort for non-critical notifications.

The evaluate step is what separates senior from staff. Naming the failure modes and what you'd add at the next scale is the operational thinking that distinguishes someone who's run systems from someone who's only designed them.

04Common Follow-Up Probes

The most common follow-up questions in chat messaging interviews. The strong responses below assume the design above is on the whiteboard.

05How This Walkthrough Composes Concepts

Chat messaging composes a slightly different set of concepts than social feed. Here's the explicit map:

• Message queues. The routing queue (Kafka) decouples Message Service writes from Delivery Worker consumption. At-least-once delivery semantics, partitioned by conversation or recipient. The same patterns from the message queues deep-dive apply directly.
• Database selection. Message store is Cassandra-class (append-heavy, point lookups by conversation, eventual consistency tolerable). Postgres works at smaller scale; dedicated KV at our scale.
• Sharding. Message store sharded by conversation ID. Gateway-routing service sharded by user ID. Each partition decision driven by access pattern.
• Replication and consistency. Cross-region replication of the message store and presence service. Eventual consistency on presence; stronger consistency on message persistence.
• Load balancing. Stateful load balancing for gateway connections (sticky to the same gateway for the duration of a connection). This is a less common pattern than stateless LB; the gateway-routing service is what makes it work.
• Rate limiting. Per-user message-send rate limits (spam prevention). Per-IP connection-establishment limits (DOS protection). Rate limiting covers the per-user vs per-IP patterns.
• Observability. Connection counts per gateway, message delivery latency p99, queue depth, presence service health, push notification success rate. Standard SLO targets around delivery latency.
• Caching. Gateway-routing cache (which gateway holds which user's connection). Recent-message cache per conversation for fast scrollback. Read-receipt aggregation cache for groups.

If you've worked through the concept library, you've already seen each of these primitives. The walkthrough composes them into a chat-specific solution; the concepts are the toolkit.

06Walkthrough FAQ