WhatsApp

Overview

WhatsApp is the world’s most popular messaging application, serving over 2 billion users across 180+ countries. Its architecture prioritizes message delivery reliability, end-to-end encryption, and minimal latency. Built on an Erlang/FreeBSD stack, WhatsApp achieves remarkable efficiency — famously supporting 900 million users with just 50 engineers.

Scale

Requirements

High-Level Architecture

Loading diagram...

Key Components

Data Model

Loading diagram...

Message Delivery Flow

When User A sends a message to User B, the following sequence occurs:

1. Client encrypts the message using the Signal Protocol (Double Ratchet Algorithm)
2. WebSocket connection transmits the encrypted payload to the gateway
3. Message Service persists the message and checks recipient status
4. If online: message is pushed through B’s WebSocket connection immediately
5. If offline: message is queued and a push notification is sent via APNs/FCM
6. Delivery receipt flows back to sender when B receives the message
7. Read receipt flows back when B opens the conversation

Messages are stored on the server only until delivered (transient storage). Once the recipient acknowledges receipt, messages are deleted from server storage, ensuring privacy.

Loading diagram...

End-to-End Encryption

WhatsApp uses the Signal Protocol for end-to-end encryption, ensuring that only the communicating users can read messages. The server never has access to plaintext content.

Key Exchange: Uses the X3DH (Extended Triple Diffie-Hellman) key agreement protocol. Each user generates an identity key pair, a signed pre-key, and a set of one-time pre-keys.

Message Encryption: The Double Ratchet Algorithm provides forward secrecy and break-in recovery. Each message uses a unique encryption key, so compromising one key doesn’t expose other messages.

Group Encryption: Uses the Sender Keys protocol. Each group member generates a sender key, distributes it via pairwise encrypted channels, then uses it for efficient group message encryption.

Erlang/OTP Architecture

WhatsApp’s backend is built on Erlang/OTP, chosen for its exceptional concurrency model and fault tolerance.

Why Erlang?

• Lightweight processes: Each connection is an Erlang process (~2KB memory), enabling millions of concurrent connections per server
• Fault isolation: Process crashes don’t affect other connections (let-it-crash philosophy)
• Hot code loading: Deployments happen without disconnecting users
• Built-in distribution: Erlang nodes communicate seamlessly in a cluster

Mnesia Database: WhatsApp uses Mnesia, Erlang’s built-in distributed database, for storing message queues and user metadata. It provides in-memory speed with optional disk persistence.

A single WhatsApp server can handle ~2 million concurrent connections, making it one of the most efficient messaging architectures ever built.

Architectural Tradeoffs

# Learn From a WhatsApp-like System

You are an expert software architect and teacher. I want to learn from a WhatsApp-inspired system design (End-to-end encrypted messaging at planetary scale) without pretending this is the exact private production architecture.

Use the following reference as a learning model. Keep assumptions visible, avoid unsupported scale claims, and explain the engineering forces behind each design choice.

---

## System Design Reference
import { Mermaid, Scale, ComponentList, ComponentCard, Requirements, Tradeoff } from '@/components/mdx';

## Overview

WhatsApp is the world's most popular messaging application, serving over 2 billion users across 180+ countries. Its architecture prioritizes message delivery reliability, end-to-end encryption, and minimal latency. Built on an Erlang/FreeBSD stack, WhatsApp achieves remarkable efficiency — famously supporting 900 million users with just 50 engineers.

## Scale

<Scale items={{
  "Monthly active users": "2B+",
  "Messages per day": "100B+",
  "Peak throughput": "~1.15M messages/second",
  "Media storage": "Petabytes",
}} />

## Requirements

<Requirements
  functional={[
    'One-on-one and group messaging',
    'Media sharing (images, video, documents)',
    'Read receipts and online presence',
    'End-to-end encryption for all messages',
    'Message synchronization across devices',
    'Voice and video calling',
  ]}
  nonFunctional={[
    'Ultra-low latency (<200ms message delivery)',
    'High availability (99.99% uptime)',
    'Strong consistency for message ordering',
    'Data privacy and encryption',
    'Minimal bandwidth usage',
    'Offline message queuing and delivery',
  ]}
/>

## High-Level Architecture

<Mermaid chart={`graph TB
    subgraph Clients
        A[Mobile App]
        B[Web Client]
        C[Desktop App]
    end
    subgraph Edge["Edge Layer"]
        LB[Load Balancer]
        GW[WebSocket Gateway]
    end
    subgraph Services["Core Services"]
        MS[Message S...

[Full prompt copied to clipboard]