Design a chat app

Send a message and it appears on your friend's phone a moment later, in order, exactly once, with a tick when it's delivered and another when it's read, even if their phone was off for a week. Chat looks simple and combines nearly every Level 4 idea: persistent connections, routing between servers, ordering, at-least-once delivery with deduplication, and offline sync. It follows the interview framework phase by phase.

1. The prompt

"Design WhatsApp" or "design Messenger": one-to-one and group chat on phones, with delivery and read receipts.

Most of the difficulty is invisible to users: routing a message between two of hundreds of connection servers, guaranteeing order and no duplicates over flaky mobile networks, and syncing a phone that was off for a week, all while the servers can't read what's being sent.

2. Frame the problem

3. What it must do

1. A user can send a message to a person or a group, and it's delivered in order, once.
2. Offline users get their messages when they return, on every device.
3. Users see receipts and presence: delivered, read, online, typing.

Not now:

• Voice and video calls: WebRTC (Module 19).
• Stories and status updates.
• Payments.
• Very large broadcast channels: mentioned in follow-ups.

Photos and videos go to blob storage, and the message carries a reference (Module 10).

4. How well it must do it

5. Numbers that change the design

6. The nouns

• User and Device.
• Conversation: direct or group, with members.
• Message.
• Receipt: delivered or read, up to a position.
• Session: which gateway holds a device's connection right now.

messages       partition (conversation_id, time_bucket) · clustering seq desc
               client_msg_id, sender_id, encrypted_body, media_ref, sent_at
conversations  conversation_id, type, members[], last_seq
devices        (user_id, device_id) → push_token, last_acked_seq per conversation
presence       online:{user} with a 30 s TTL (soft state, in memory)

7. The contract

A WebSocket while the app is open (both directions), plus HTTPS for sync and media uploads. The user and device come from the authenticated session.

// over the WebSocket, both directions
→ send     {client_msg_id: "c9f1…", conversation_id, body}
← ack      {client_msg_id: "c9f1…", seq: 1043}            (stored: one tick)
← message  {conversation_id, seq: 1043, sender, body}
→ receipt  {conversation_id, up_to_seq: 1043, type: "delivered" | "read"}
// over HTTPS
GET /v1/conversations/{id}/messages?after_seq=1040&limit=100   (sync after reconnect)

8. First working version

Gateway servers holding WebSockets, a chat service, a message store and a push service.

8.1 Sending to someone online

The chat service stores the message, assigns its sequence number, acknowledges to the sender, then delivers it to the recipient's connection. Version one keeps a table of "which gateway holds which user".

8.2 Someone offline

The message is already stored; the chat service sends a push notification. When the app opens, it fetches messages after its last sequence number.

8.3 Receipts

When Ravi's phone shows the message, it sends "delivered up to 1043"; when he opens the chat, "read up to 1043". The chat service forwards them to Asha like any other message.

9. Make it hold up

9.1 Ordering and duplicates in order · never duplicated

9.2 Getting the message to the right server fast · scale

Asha's phone is connected to gateway 12, Ravi's to gateway 87. Gateways are thin: they hold connections and nothing else, so deploying chat logic doesn't drop 50M connections. When Ravi connects, gateway 87 subscribes to his channel in a sharded pub/sub layer (or registers "Ravi → gateway 87" in a session store with a TTL). The chat service stores the message, then publishes it to Ravi's channel; whichever gateway holds Ravi's connection pushes it down (Module 19).

9.3 Offline users, receipts and sync never lost · bad networks

• If Ravi isn't connected, nothing is subscribed: the message is already stored, so the chat service sends a push notification (APNs or FCM) to wake his phone.
• When the app connects, it sends, per conversation, the last sequence number it has, and fetches everything after it: sync by sequence. This also covers flaky networks that drop messages in flight.
• Receipts are just messages flowing the other way: "delivered up to 1043", "read up to 1043". A high-water mark instead of one receipt per message keeps them cheap.
• Each device tracks its own position, so the same history syncs to a phone, a laptop and a tablet.

9.4 Storing billions of messages scale · never lost

Writes dominate, and the read pattern is always "the latest messages in this conversation, then older ones": a perfect fit for a wide-column store such as Cassandra or ScyllaDB (Discord has written about its message storage), partitioned by (conversation_id, time bucket) and clustered by sequence, newest first (Module 13). Buckets keep huge, years-old groups from becoming giant partitions. Some apps keep messages on servers only until all devices have them; others keep full history. That choice changes storage by orders of magnitude, so ask.

9.5 Group chats scale

A message to a 500-member group is stored once in the group's conversation; delivery fans out to the members' channels (and push notifications for offline members). For very large groups or channels, members fetch on demand rather than receiving every message pushed, much like the celebrity case in Design D06. With end-to-end encryption, the sender's device encrypts for each member device (or uses a shared group-key scheme), one reason group sizes are capped.

9.6 Presence and typing scale · bad networks

Presence is soft state: each connection's heartbeat refreshes online:ravi with a 30-second TTL, and expiry means offline. Only send presence changes to people who are looking at the conversation, and throttle typing indicators. At 50M users, unfiltered presence updates would outnumber real messages. Losing a presence update is harmless; the next heartbeat fixes it.

9.7 End-to-end encryption private

With the Signal protocol (used by WhatsApp and Signal), keys live on devices; servers store and forward ciphertext they can't read. The server still knows metadata (who messaged whom, and when) and must deliver to every device of each recipient, since each device has its own keys. This rules out server-side search of message content and shapes how history reaches a new device.

9.8 The whole design after the deep dives

"See you at 7" from Asha to Ravi, then Ravi's laptop catching up later.

10. Interviewer follow-ups

Variation: community servers with channels

Another common form: "Design chat for communities, like Discord: servers with many channels, some with hundreds of thousands of members." One-to-one delivery still works, but the unit changes from a conversation to a channel inside a server, and most members of a big server are offline or looking at another channel.

• Fan-out by who is looking. One process per server (sharded by server ID) keeps the server's online sessions in memory. A new message is pushed in full only to sessions that have that channel open or are mentioned. Everyone else gets, at most, a batched "unread" marker.
• Unread without a row per member. Store, per member, the last message ID they read in each channel. A channel is unread when its latest ID is higher. Nothing is written for the 800,000 members who didn't open it.
• Messages by channel and time window. Partition by (channel, time window) with time-ordered IDs (Module 20), so a busy channel never grows one huge partition and history is one range read. A very busy channel needs smaller windows.
• Permissions as roles. A member's rights in a channel come from their roles plus the channel's overrides. The server process caches the result, so each message is checked in memory.
• Member list on demand. The sidebar loads only the part of the member list on screen, grouped by role and online status.
• Voice is a separate system. The chat connection carries the signalling; the audio goes over UDP to media servers that forward each speaker's stream to the listeners. Say so and keep it out of scope unless asked.

Read more: Discord's engineering blog on storing messages by channel and time bucket and on one process per server.

11. When things break

12. Wrap-up and the clock

Trade-offs we made:

• Per-conversation order, not global order.
• Thin gateways and pub/sub routing.
• Store first, then deliver (latency for safety).
• High-water-mark receipts.
• Soft presence.
• End-to-end encryption, at the cost of server-side features.

What we'd watch:

• Send-to-deliver latency p99.
• Connections per gateway.
• Reconnect rate.
• Sync lag.
• Store write latency.
• Push success rate.

At 10×:

• More gateways and pub/sub shards.
• Colder storage tiers.
• Regional homing.

Common mistakes:

• Ordering by timestamps.
• Delivering before storing.
• Relying on pub/sub for offline users.
• One receipt per message.
• Broadcasting presence to everyone.
• Forgetting multiple devices.

13. Try it, check yourself, read more

Send messages between two phones, take one offline, and watch the ticks: ✓ stored on the server, ✓✓ delivered to the other phone, ✓✓ read.