WhatsApp Messaging at Scale
WhatsApp messaging architecture: Erlang concurrency, end-to-end encryption, and handling billions of messages daily.
What is a WhatsApp-style messaging system?
A WhatsApp-style messaging system is a private, real-time delivery network that accepts a message from one device, routes encrypted copies to the recipient's devices, and keeps retrying safely when a device is offline or an acknowledgement is lost.
In plain language: the sender's device turns readable text into ciphertext before upload. The service moves and temporarily stores that unreadable envelope. Each recipient device then authenticates, decrypts, stores, and acknowledges its own copy. This separation matters because phones disconnect often, one person may have several devices, and a retry must not create a second visible message.
Core invariant
One logical message keeps one stable identity, remains encrypted while the service handles it, and has independent delivery state for every recipient device. Retries may repeat transport work, but they must not repeat the visible message or let one device's acknowledgement erase another device's pending copy.
This case study uses an illustrative planning envelope rather than claims about WhatsApp's current production fleet. It focuses on text delivery, long-lived connections, temporary offline storage, multi-device acknowledgement, and end-to-end encryption. Review Concurrency Patterns first if isolated actors, mailboxes, and supervision are unfamiliar.
The product promise separates acceptance, delivery, and reading
A sender wants a fast, honest result. A recipient expects private content, prompt delivery when online, and eventual catch-up after reconnect. Those expectations are related, but they are not one distributed transaction across every device.
Functional requirements
- Send one-to-one and group text messages from mobile, web, or desktop clients.
- Encrypt content on the sender and decrypt only on intended recipient devices.
- Deliver to online devices promptly and retain bounded ciphertext work for offline devices.
- Synchronize linked devices without duplicate display when retries or reconnects occur.
- Expose sent, device-delivered, and read states as separate evidence.
- Upload media through a separate object path so large files do not block chat envelopes.
Non-functional requirements
- Acknowledge sender acceptance only after authorized encrypted work is durable and replayable.
- Target sub-second connected delivery while keeping queue age bounded during bursts.
- Preserve one logical message identity across retries and one independent status per recipient device.
- Keep plaintext and content keys outside routing, queue, and storage services.
- Isolate a large group, reconnect wave, or failed partition from unrelated conversations.
- Expire undelivered ciphertext according to an explicit retention contract.
State names must tell the truth
- Accepted means the service durably owns authorized ciphertext delivery work.
- Device delivered means one named recipient device persisted and acknowledged its envelope.
- Read is a later recipient-generated event and may be disabled by product policy.
- Pending means at least one intended device still lacks an acknowledgement.
- Expired means the bounded server queue will no longer retry; it does not imply delivery.
Scope boundary
This design does not cover voice calls, video transport, contact discovery, backup encryption, search, or the policy details of abuse moderation. Those systems have different data, latency, and trust boundaries. The message router may use privacy-compatible metadata controls and user reports, but it cannot assume access to message plaintext.