Design WhatsApp

Design a chat app like WhatsApp: one-to-one and small group messaging, delivered in real time, with online status and message history across devices.

1. Clarify the requirements

Before drawing anything, ask questions. These are the answers an interviewer would typically give:

How many users?

50 million DAU. Each sends about 40 messages a day.

Group size?

Groups of up to 100 members.

Which features?

1:1 chat, group chat, online presence, multi-device sync and push notifications when offline. Media is optional; voice/video calls are out of scope.

How long is history kept?

Forever.

Encryption?

End-to-end encryption is a nice-to-have; mention it.

Message size?

Text messages up to 100,000 characters; average ~100 bytes.

Latency?

Messages should arrive in well under a second when both users are online.

2. Estimate the scale

Assumptions: 50M DAU, 40 messages per user per day, ~100 bytes per message (store forever, ignore replication).

• Messages per second: about 23K msg/s50M × 40 ÷ 86,400 ≈ 23K messages/s.
• Message storage per day: about 200 GB2B messages × 100 B = 200 GB/day.
• Concurrent WebSocket connections (assume 20% of DAU online): about 10M connections50M × 20% = 10M open connections, spread over many chat servers.

3. The high-level design

1. Phones keep a connection openEach online phone holds a WebSocket to a chat server, so messages are pushed instantly in both directions.
2. Store every messageChat history is huge and read by recency: a key-value / wide-column store partitioned by conversation ID, with per-conversation message IDs that keep order.
3. Who's onlinePresence is a heartbeat every few seconds stored with a short TTL: no heartbeat for 30 s means offline. Friends are told when it changes.
4. Offline users get a pushIf the recipient isn't connected, the message waits in a queue and push workers notify their phone through APNs/FCM.
5. Watch it in productionMetrics and alerts close the loop: connections per server, delivery latency and offline backlog.

4. The components and what each one does

Load balancer Load balancer

Routes each WebSocket to a chat server; service discovery (ZooKeeper) picks the least-loaded one.

Chat servers App servers

Hold a WebSocket per online user. Stateless apart from the connections: if one dies, clients reconnect elsewhere.

Message store NoSQL / KV store · Cassandra / HBase

Partitioned by conversation (channel) ID; ordered message IDs; 3 replicas with automatic failover to a copy if a node dies. Devices sync from their last message ID.

Presence (Redis) Cache · Redis

Online status from heartbeats, with a TTL.

Message queue Event stream

Messages for offline users and group inboxes.

Push workers Workers

Send push notifications for offline recipients.

Metrics & alerts Metrics & alerts

Dashboards and alerts on p99 latency, error rate, queue depth and cache hit ratio, so a bottleneck shows up before it becomes an outage.

5. Deep dive: real-time delivery, sync and presence

How does a message get from sender to recipient in real time? What if the recipient is offline or on several devices? How does online status work?

• Keep a persistent WebSocket between each client and a chat server.
• Messages are stored first, then delivered; offline users get a push notification and sync on reconnect.
• Each device tracks the last message ID it has seen. Presence uses heartbeats.

6. What interviewers listen for

• Message & sync APIDefine sending and syncing (fetch messages after the last ID a device has).
• Message data modelMessages keyed by conversation and an ordered message ID.
• WebSocket (persistent bidirectional connection)The server must push messages; WebSockets are the standard choice.
• Heartbeats for presenceMark users offline only after missed heartbeats, so flaky networks don't flicker.
• Service discovery to pick a chat serverClients need to be assigned a chat server (by region and load), and reconnect elsewhere when it dies.
• Ordered message IDs and multi-device syncOrdered IDs let each device fetch only messages newer than the last one it saw.
• End-to-end encryptionOnly sender and recipient should be able to read messages.
• Database replication and failoverA single database is a single point of failure. Replicas give redundancy and read capacity; failover promotes a replica when the primary dies.
• Partition (shard) data as it growsOne machine eventually can't hold the data or the write load. Say how you'd split it and by which key.

7. Follow-up questions

1. A chat server holding 200,000 open connections crashes. What happens to those users and their in-flight messages?
2. Bob's phone is off for two days. What happens to messages sent to him, and what happens when he turns it on?
3. Product wants groups of 100,000 members. What breaks in your design?
4. Two messages sent a millisecond apart arrive in the wrong order on another device. How do you guarantee order?

The design in a nutshell

• Clients keep a WebSocket to a chat server chosen by service discovery; stateless API servers handle login, profiles, groups.
• Send: chat server assigns an ordered message ID, stores the message in a sharded KV store (by conversation), then delivers to the recipient's chat server or a push notification if offline.
• Each device tracks cur_max_message_id and syncs newer messages on reconnect.
• Groups: message copied to members' inboxes (small groups); presence servers track heartbeats and publish status to friends.
• Replication for the KV store, resend + dedup by message ID, monitoring connection counts and delivery latency.

Related lessons: Polling vs long polling vs WebSocket · 1-on-1 message flow · Syncing messages across multiple devices · Online presence