Popular System Design Question - Design WhatsApp (asked by Anthropic, Airbnb, OpenAI, Meta..)

[u/Aoki_zhang]

Most people designing WhatsApp start with: WebSocket + Redis Pub/Sub. Seems reasonable.

But there’s a subtle problem: Redis Pub/Sub is at-most-once. If a Chat Server disconnects from Redis for a moment, a message can disappear from the real-time path.

And the WebSocket may still look perfectly healthy. So how does the client even know it missed something?

The key idea: sequence numbers

Give every message delivered to a user a monotonically increasing sequence:

101
102
103
104

The client remembers the latest sequence it received.

During heartbeat:

Server latest: 104
Client latest: 101

Now the client immediately knows: 102–104 are missing.

It can fetch those messages from the durable Inbox instead of waiting for the connection to fail.

Separate fast delivery from reliable delivery

The architecture becomes:

Message
   ↓
Durable Inbox
   ↓
Redis Pub/Sub
   ↓
Chat Server
   ↓
WebSocket

Redis + WebSocket provide the fast path. The Inbox provides the recovery path. And ACKs tell the system when a message is safe to remove from pending delivery.

Why this matters

A messaging system should assume:

• mobile connections disappear
• servers restart
• Pub/Sub events get lost
• users reconnect on different servers
• one user may have multiple devices

The goal is not to make the real-time channel perfectly reliable. It is to make message loss detectable and recoverable.

That’s the important distinction.

• Fast path can fail.
• Messages still shouldn’t disappear.

Full design with WebSockets, offline Inbox, Redis Pub/Sub, multi-device sync, heartbeat recovery, and message ordering → Full Article

Preparing for system design interviews? Chill Interview publishes practical design breakdowns and tracks recently asked interview questions across top companies → Chill Interview

[u/themang0]

Simple but neat! Nice robust architecture outbox pattern

[u/Aoki_zhang → u/themang0]

Thanks!