How WhatsApp Scaled to 450 M Daily Users with Only 32 Engineers

Single Responsibility Principle

WhatsApp limited its product to the core messaging function, deliberately avoiding ad networks, social features, and other non‑essential components. This focus prevented feature creep and helped maintain high reliability.

Technology Stack

The server core was built in Erlang and deployed on FreeBSD . Erlang was chosen for its small binary size, lightweight processes, cheap context switches, and built‑in hot code loading, which enables code updates without restarting services.

Erlang Advantages

Small footprint and high scalability

Native lightweight processes (no OS thread overhead)

Hot code loading for zero‑downtime deployments

FreeBSD provided a reliable network stack and was tuned (kernel parameters, file‑descriptor limits, socket buffer sizes) to support more than two million concurrent connections per server.

Avoid Reinventing the Wheel

WhatsApp built on the open‑source XMPP server ejabberd (written in Erlang) rather than creating a messaging server from scratch. Select core components of ejabberd were rewritten to meet specific requirements, and third‑party services such as Google Push were used for push notifications.

Cross‑cutting Concerns

The team emphasized system‑wide concerns such as monitoring, health‑checking, and alerting. Continuous integration (CI) merged code changes regularly into a central repository, while continuous delivery (CD) automated deployment to test and production environments.

Scalability Strategies

WhatsApp employed diagonal scaling , a combination of horizontal scaling (adding more machines) and vertical scaling (adding CPU/memory to existing machines). This reduced cost and operational complexity.

Key scaling actions included:

Over‑provisioning each server to absorb traffic spikes and tolerate hardware or network failures.

Adjusting FreeBSD kernel parameters, e.g.,

sysctl -w kern.maxfiles=2000000
sysctl -w kern.maxfilesperproc=2000000
ulimit -n 2000000

to raise file‑descriptor and socket limits.

Running on FreeBSD for its stable TCP/IP stack and familiarity within the engineering team.

Flywheel Effect

Performance metrics such as CPU utilization, context‑switch rate, and system‑call count were measured continuously. Identified bottlenecks were eliminated in short feedback cycles, creating a self‑reinforcing performance improvement loop.

Quality Testing

Load testing was used to discover single points of failure. The process generated artificial traffic and performed DNS configuration changes to simulate real‑world load patterns. Results guided capacity planning and redundancy improvements.

Team Size Management

To keep communication overhead low, WhatsApp capped its engineering staff at 32 engineers. Communication paths grow quadratically with team size, so a small, tightly‑coordinated team preserved productivity.