Design WhatsApp: Real-Time Chat, Offline Delivery and Group Messages

The core feature is one-to-one messaging: a user sends text to another user and it arrives in real time. Group chats extend that to conversations of up to roughly a thousand members, which is large enough to stress delivery but small enough to keep fan-out bounded.

Two requirements make the system more than a relay. Messages to an offline person must be held and handed over when that person reconnects, a store-and-forward model. And the sender sees per-message status through sent, delivered and read indicators, which means the backend must track acknowledgements, not just push bytes. Voice and video calling, status stories and payments are excluded since each is a large product in itself.

When both participants are online, a message should arrive in under 500 ms; anything slower makes a conversation feel laggy. Delivery is guaranteed: once the sender's phone shows a single tick, the message must survive server crashes and a recipient who stays offline for days. In practice that means at-least-once delivery combined with deduplication.

Order within a chat must be preserved, so an answer never shows up above the question it responds to. And all of this has to hold at enormous scale, with something like 500 million devices holding open connections simultaneously. That last requirement shapes the architecture more than any other.

Assume around 1 billion daily active users, each sending roughly 40 messages a day. That is about 40 billion messages daily, or approximately 460K per second on average, with peaks close to 1 million per second.

Connections matter even more than message rate. At peak, perhaps 500 million phones are online at once. If a single well-tuned server holds about 500K mostly idle sockets, we need on the order of 1,000 chat servers just to keep those connections alive. Storage is comparatively modest: at about 100 bytes per text, the daily volume is near 4 TB, and messages only live on the server until they are delivered. The conclusion is that the connection layer, and fast routing between connections, is the center of the design.

The entities are User, Chat (either one-to-one or a group), Message and Device. Device is listed separately because one person may have several, and each holds its own connection and its own delivery state.

Rather than a REST call per message, every device opens a single WebSocket at /connect and keeps it alive. Sending is a send_message event carrying the chat ID, the text and a client-generated message ID; the server answers with an ack containing the server message ID and a sequence number. Incoming messages arrive as server-pushed new_message events, and the device must reply with an ack of its own so the server knows delivery succeeded. Infrequent setup operations, like creating a group, still use plain HTTP such as POST /chats.

Each phone maintains one WebSocket to a chat server, which is what lets the backend push a message the instant it exists rather than waiting to be asked. Suppose Alice, connected to chat server A, messages Bob. Server A hands the message to a message service, which first writes it to a message store such as Cassandra, in Bob's inbox, and then acknowledges Alice. That durable write is what earns the first tick.

Next the message service consults a session registry, a Redis map from user ID to the chat server currently holding that user's socket. It learns that Bob is on server B, relays the payload to that machine, which writes it onto Bob's open socket. When Bob's phone acknowledges receipt, Alice's message gains its second tick and the inbox entry is removed. If the registry shows Bob is offline, the message simply stays in his inbox and a push notification nudges his phone to reconnect.

Short polling has the phone ask every few seconds whether anything new has arrived. It works over plain HTTP, but almost every response is empty, and a message can sit undelivered for a full polling interval. Long polling improves latency by holding each request open until data appears, yet the client must re-establish the request after every delivery, and the channel only flows from server to client.

WebSockets keep one connection open in both directions with only a few bytes of framing per message, which suits chat perfectly. The cost is statefulness: a chat server now owns specific users, which complicates deploys and failover. Because most sockets are idle most of the time, an event-driven networking stack such as Netty lets one machine hold around half a million of them.

Phones send a small heartbeat every 30 seconds, and each registry entry carries a TTL, so a device that silently disappears ages out of the registry instead of attracting misrouted messages. When a chat server dies, its devices fail over by connecting to a healthy peer and then catch up on anything delivered while they were away. WebSockets win on latency and efficiency.

Reliability starts on the phone. Every outgoing message gets a unique client-generated ID, so if the network drops and the app resends, the server recognizes the duplicate and discards it. The server then persists before it promises anything: the message is written to the recipient's inbox, and only after that write succeeds does the sender receive an ack. A single tick therefore means the message is safely stored, not merely in flight.

Delivery follows. An online recipient gets the message pushed over the socket; an offline one keeps it in the inbox and receives a push notification. When the recipient's device acknowledges, the sender sees a second tick and the inbox entry is deleted.

Reconnection closes the loop. A phone coming back online asks for every message after the last sequence number it has, so gaps are impossible. The server assigns that sequence number per chat at write time, which gives one authoritative order that every device sorts by. Retries prevent loss, and client IDs prevent duplicates from appearing in the conversation.

A message to a 1,000-member group means up to 1,000 deliveries, so each step is made cheaper. Group membership is cached, which avoids a database read on every message. The session registry is then used to bucket members by the chat server they are connected to; if 200 members share one server, the message service makes one call to it instead of 200.

For larger groups, fan-out is handed to Kafka. The sender receives an ack as soon as the message is stored, and background workers fan it out to members over the following moments. Offline members receive an inbox entry, either a copy or a pointer to the stored message, which they collect on reconnect.

Finally, group size is capped at around a thousand members, which keeps the worst-case cost of a single message predictable. Audiences much larger than that call for a separate broadcast-style channel rather than a chat group.

Persistent sockets give near-zero delivery delay and minimal per-message overhead, yet servers that own live connections are harder to roll out, rebalance and recover. Deleting messages once delivered cuts storage and improves privacy, while leaving chat history to live on the device and its backups rather than on the server.

At-least-once delivery with deduplication guarantees nothing is lost, but every client has to discard repeats using the message ID. Fanning group messages out on write gives members fast reads, at a cost that rises linearly with group size, which is why the cap matters. Summed up: store a message before acknowledging it, push it over open sockets, and require an ack at every hop.