Design WhatsApp - System Design for Messaging Applications

We will design a small messaging service: a sender writes a message, a recipient may be offline and both clients need understandable delivery status. This is an educational design, not WhatsApp’s internal architecture.

Assume one-to-one text conversations initially, with 50,000 simultaneously connected clients and 2,000 submitted messages per second at a planned peak. Groups, calls and large media are separate extensions. These values are requirements for discussion, not product measurements.

“Accepted” can mean the server durably recorded a message under its contract. “Delivered” can mean a recipient device acknowledged receipt. “Read” is an application-level signal and does not prove what a person actually understood.

A client-generated stable message/action identifier lets a sender retry an uncertain submission without intentionally creating another message. The server needs a correctly enforced deduplication and durability rule, including concurrent requests.

A connection closing after send leaves uncertainty. Do not equate a lost acknowledgement with a failed write. Let the client query or retry the same intended action.

A WebSocket can carry bidirectional traffic while a connection is open. A connection gateway tracks where an active device can receive messages, while durable message state supports offline delivery and reconnect.

Presence is often approximate and can become stale after a disconnect. A routing map should not be treated as proof that a device received a message. Reconnect should request messages after a persisted cursor or sequence boundary.

Define ordering scope, such as a conversation sequence assigned by an authoritative mechanism. Multiple senders, retries and devices need a rule; local wall-clock timestamps alone do not prove one global order.

The demo submits the same action ID, msg-1, containing “Hello”. Stable-ID mode stores one logical message even after a repeated submission. Naive mode appends a message for each submission.

The recipient begins offline. Delivery waits until it is online; repeated delivery passes do not add already-delivered stored IDs in this local model. A separate button marks delivered messages read. All state is in memory here, so reset erases it; production durability and encryption are not implemented by this exercise.

Decide how long undelivered messages are retained and what happens when a device returns after that limit. Each device may need its own acknowledgement and cursor. A user-level delivery checkmark should have a documented interpretation.

Group messaging multiplies recipients and changes membership rules. A former member must not obtain later messages merely because a cached recipient list is old. Media needs separate upload, access and expiry handling.

Protect message access and minimise metadata retention. Transport encryption and end-to-end encryption are different properties. If end-to-end encryption is required, use reviewed protocols and implementations; key verification, device changes and backups need explicit designs.

The WebSocket API supports persistent bidirectional communication. A durable database or log, queue and connection routing service can have separate roles. Source checked 6 October 2026; the transport does not itself persist messages or define delivery semantics.

Plan connection count, per-message payloads, offline backlog and fan-out separately. Test reconnect storms and slow clients; bound buffers and apply appropriate admission controls.

Start with one-to-one delivery and a clear status contract. Add group and multi-device behaviour only with matching access, sequence and recovery tests.

Compare local Observer callbacks with broker-mediated subscriptions. Use a stable retry contract for uncertain submission; none of these names alone proves durable or exactly-once delivery.

Give submissions stable identities, persist the intended state and distinguish acceptance, delivery and reading. Reconnect needs cursors, retention and ordering rules.

Plan device membership, privacy and the required encryption contract. Test uncertain acknowledgements and repeated delivery, not just an open connection.