KnowledgeCafé

How 50 Engineers Scaled WhatsApp to 2 Billion?

Meta Engineering
engineering meta whatsapp scalability

Imagine managing a communication network larger than the population of most continents. Every single day, billions of people open an app to send text messages, share photos, and make voice calls. Now, imagine running that entire global operation with a core engineering team small enough to fit inside a single conference room. When Facebook acquired WhatsApp for $19 billion, tech circles were stunned by a startling metric: WhatsApp had over 450 million active users but employed just 32 engineers.As the platform scaled past 2 billion users, that core engineering team only grew to around 50 people.How did they do it? They didn’t rely on massive infrastructure bloat or endless hiring cycles. Instead, WhatsApp achieved legendary status in system design by mastering a philosophy of radical minimalism, vertical scaling, and picking the absolute perfect tool for the job.

1. The Foundation:

Why Erlang Was the Secret WeaponIf you ask a modern software engineer how to build a scalable chat app, they might suggest a microservices architecture using Go, Node.js, and Kubernetes. WhatsApp did the exact opposite. They built their system around Erlang, a programming language designed by Swedish telecom company Ericsson in the 1980s.Erlang wasn’t chosen because it was trendy; it was chosen because it was built from the ground up to solve one specific problem: managing millions of concurrent phone calls without crashing.

The Lightweight Process Model

In most languages, handling a user connection requires OS threads or heavy memory allocation. Erlang uses isolated, lightweight green threads (called processes) managed by its own virtual machine (BEAM).A typical OS thread can consume up to 1MB of memory.An Erlang process consumes as little as 2.6 KB.This meant a single WhatsApp server could easily hold millions of concurrent user connections.

graph TD
    UserA[User A Connection] -->|Handled by| P1[Erlang Process 1 - 2.6KB]
    UserB[User B Connection] -->|Handled by| P2[Erlang Process 2 - 2.6KB]
    UserC[User C Connection] -->|Handled by| P3[Erlang Process 3 - 2.6KB]
    
    subgraph BEAM [Erlang BEAM Virtual Machine]
        P1
        P2
        P3
    end
    
    subgraph Hardware [Single Server Node]
        BEAM
    end

Hot Code Loading

When you have 2 billion users, you cannot schedule a “maintenance window” to deploy an update. If the app goes down for 10 minutes, global communication stalls. Erlang allows for Hot Code Loading—the ability to deploy backend code updates to production servers while they are actively processing live traffic, with zero downtime.

2. Breaking the “Million Connection” Barrier

In the early 2010s, standard tech industry practice was horizontal scaling—when your app gets busy, you just buy more servers. WhatsApp’s team found this approach messy. More servers meant more network complexity, higher costs, and more things to monitor.They chose vertical scaling: pushing a single hardware server to its absolute physical limits.The team set a benchmark to get 2 million concurrent connections on a single machine. To achieve this, they had to systematically hack the FreeBSD operating system kernel:

  • Tuning the Network Stack: They modified the kernel’s socket allocation arrays to stop it from running out of file descriptors.
  • Eliminating Locks: They identified bottlenecks where CPU cores were waiting on each other (lock contention) and rewritten parts of Erlang’s memory allocation to allow truly parallel operations. By optimizing the software to fit the hardware, they drastically reduced their server footprint. Fewer servers meant fewer problems, allowing a tiny team to manage the entire fleet.

3. The Elegance of Ephemeral Data Storage

Databases are almost always the biggest bottleneck in system design. As data grows, queries slow down, indexes fragment, and hard drives saturate. WhatsApp solved this with a beautiful, architectural loop-hole: they don’t store your messages.WhatsApp operates as an ephemeral, stateless messaging pipeline, not a data warehouse.Code

sequenceDiagram
    autonumber
    actor Sender as User A (Sender)
    participant Server as WhatsApp Erlang Server
    participant DB as Ephemeral Queue
    actor Recipient as User B (Recipient)

    Sender->>Server: Sends Message (Encrypted)
    alt Recipient is Online
        Server->>Recipient: Delivers Message Immediately
        Recipient-->>Server: Acknowledges Delivery
        Server-->>Sender: Updates Status (Double Checkmark)
    else Recipient is Offline
        Server->>DB: Stores Message Temporarily
        Note over DB: Sits in queue until User B wakes up
        Recipient->>Server: Connects to Network
        Server->>DB: Fetches Queued Messages
        Server->>Recipient: Delivers Message
        Recipient-->>Server: Acknowledges Delivery
        Server->>DB: Wipes Message Permanently from Disk
    end

The Delivery Lifecycle

  • User A sends an end-to-end encrypted message to User B.
  • If User B is online, the Erlang server acts as a pure router. It passes the message directly through the open connection and forgets it immediately.
  • If User B is offline, the message is stored temporarily in an ephemeral queue database.
  • The exact microsecond User B comes back online, the backlog is pushed to their device, and the messages are permanently deleted from WhatsApp’s servers. Because your chat history lives entirely on your physical phone (and your personal cloud backup) rather than WhatsApp’s servers, their database load remains incredibly light, regardless of whether they have 10 million or 2 billion users.

4. Keeping Multimedia Lean

While text messages are computationally cheap, photos, videos, and voice notes are incredibly heavy. To handle petabytes of media uploads without melting their bandwidth, WhatsApp designed a decoupled media delivery architecture.When you upload a photo, it doesn’t pass through the core Erlang chat servers. Instead, WhatsApp separates the control plane (chat state) from the data plane (media content):

graph TD
    UserA[User A] -->|1. Uploads encrypted media| CDN[Media Store / CDN]
    CDN -->|2. Returns Unique URL & Thumbnail| UserA
    UserA -->|3. Sends Chat Message containing URL| Server[Core Erlang Server]
    Server -->|4. Routes text payload| UserB[User B]
    UserB -->|5. Fetches heavy file via URL| CDN

    subgraph Data Plane [Data Plane - Heavy Traffic]
        CDN
    end

    subgraph Control Plane [Control Plane - Light Traffic]
        Server
    end

By offloading heavy assets to edge Content Delivery Networks (CDNs), the core Erlang infrastructure only has to worry about coordinating small text payloads, keeping latency near zero.

5. The Engineering Culture of Minimalism

Beyond the code and the protocols, WhatsApp’s biggest scaling secret was their strict, borderline obsessive engineering culture. They operated on a few uncompromising rules:

  • No Boredom-Driven Development: They resisted the urge to adopt trendy frameworks or rewrite working code just because something new came along. They stayed with Erlang and FreeBSD for over a decade.
  • Zero Marketing Bloat: For years, WhatsApp didn’t collect user data, tracking cookies, or serve ads. By eliminating tracking scripts and heavy analytics engines, they eliminated roughly 70% of the data processing overhead that plagues typical social media backends.
  • Automate Everything: If a server node misbehaved, engineers didn’t log in to debug it. Automated scripts tore it down, spun up a clean instance, and re-routed traffic instantly.

Summary

The story of WhatsApp proves that massive scale doesn’t require massive teams or over-engineered microservices. By picking a language uniquely suited for concurrency (Erlang), choosing vertical efficiency over horizontal sprawl, keeping data storage strictly ephemeral, and maintaining a culture focused entirely on simplicity, 50 engineers built a communication platform that keeps a quarter of the human population connected.

Enjoyed this deep dive? Staying updated on architectural shifts shouldn’t be a full-time job. At Knowledge Cafe, we act as your personal research team, filtering the fluff from the world’s top engineering blogs to bring you the insights needed to build the next generation of resilient systems.

Subscribe to Knowledge Cafe here