How WhatsApp Works: System Design, Tech Stack, and Lessons for Building Your Own Chat

WhatsApp was acquired in 2014 for $19 billion. At the time, it had 450 million users and 55 engineers. The ratio – users to engineers – was treated as a joke. Now that number is closer to 3.3 billion users, and the engineering team still wouldn’t fill a conference room at a mid-sized tech company.

WhatsApp scalability is a function of specific technology choices made in 2009 that turned out to be right in ways the founders couldn’t have fully predicted. This article is a teardown of those choices – the backend stack, the message protocol, the cryptography, the multi-device rearchitecture they had to do in 2021, and what you should actually take from it when building your own chat.

Quick note: As WhatsApp has never published its full architecture document, we had to take some Meta Engineering blog posts, interviews, public talks, and Signal Protocol documentation to write this post. So, if something isn’t a confirmed fact, we’ll state it so.

The Scale of the Problem

Before the architecture makes sense, the numbers have to land:

• 3.3 billion monthly active users (2025, Backlinko) 
• ~150B messages delivered per day (SQ Magazine)
• 7B voice messages sent daily 
• 180+ countries where it operates

Every message is end-to-end encrypted – the server routes the ciphertext without being able to read it. It works offline (queued until the recipient reconnects). It works on 2G. Since 2021, the same account syncs across a phone plus up to four linked devices simultaneously, each with its own encryption state. Status, Communities, Channels, and the Business API all run on the same backbone.

Those constraints – content-blind routing, global low latency, offline delivery, exactly-once receipt semantics, mobile-first, multi-device – aren’t soft requirements. Each one has architectural implications, and the stack makes sense only when you see them as hard constraints that the founders set from the beginning.

Frontend: Native Per Platform

WhatsApp made a bet early that most developers in the 2010s were moving away from: one native app per platform, not a shared cross-platform codebase.

• Android – Java, later Kotlin, as it became standard
• iOS – Objective-C, later Swift
• Web – JavaScript. Before 2021, the web client was essentially a thin relay that required the phone to be on. Multi-device made the web a full peer with its own encryption identity
• macOS/Windows – native clients, macOS using Catalyst to share iOS code where possible

Every client stores messages locally in SQLite. The server is not a message archive – it’s a queue that holds encrypted payloads until the recipient comes online, then delivers and discards. If you delete the app, your message history is gone unless you had cloud backup enabled. 

History sync in the multi-device era works through end-to-end encrypted direct device-to-device transfers – not by pulling from a server. When you link a new device, the phone transfers a chunk of recent history directly. The server never sees the decrypted history, even during sync. This is one of those details that sounds like a footnote but represents a significant engineering constraint on the sync design.

WhatsApp Backend: The Erlang/BEAM Advantage

What’s confirmed vs inferred: The use of Erlang, FreeBSD, and XMPP-derived protocols is well documented in early talks and interviews. Mnesia for short-term state is cited in several technical talks from 2012 to 2014. Meta’s specific current infrastructure (post-2017 data center migration) is not public. The persistent storage layer likely uses Meta-internal systems; specifics are inferred.

---

Jan Koum and his early team picked Erlang, a functional language that Ericsson created in the late ’80s for their fault-tolerant telecom switches. They liked the idea of each user connection running as a separate, lightweight process – not an OS thread, which means Erlang processes only use a few hundred bytes. So they used it for the WhatsApp backend.

The BEAM VM handles preemptive scheduling across CPU cores, meaning no single process can block others. It supports hot code reloading – you can deploy new versions of the application without dropping live connections. For a messaging system that needs to stay up continuously while the team pushes updates, that’s not a luxury. It’s the only way to operate at their scale without maintenance windows.

Rick Reed gave a talk at the Erlang Factory in 2012 describing a single machine handling two million simultaneous TCP connections. The number got attention. The interesting part isn’t the headline – it’s what infrastructure that number implies. Most server stacks at the time would have needed dozens of machines to replicate it.

FreeBSD

The founders had Yahoo! backgrounds where FreeBSD was the server OS of choice, and they carried that preference to WhatsApp. FreeBSD’s networking stack has a different character from Linux – it handles very high numbers of concurrent TCP connections efficiently. Some reports describe WhatsApp running FreeBSD boxes that maintained 2-3 million concurrent connections each. It’s hard to verify whether it’s really accurate, but the claim that FreeBSD handled its concurrency model better aligns with publicly available info on both systems.

Ejabberd (heavily forked)

WhatsApp started with Ejabberd, an open-source XMPP server written in Erlang. By the time the scale numbers became public, what they were running was described internally as barely recognizable from the upstream open-source version. The codebase had been extended with a custom binary protocol, mobile optimizations, offline queuing, and proprietary group mechanics that weren’t part of standard XMPP. The connection to Ejabberd is more historical than technical at this point.

Mnesia and storage

Mnesia is Erlang’s built-in distributed database – a mix of in-memory and on-disk tables that integrates natively with the BEAM. WhatsApp used it for live connection state, session data, and short-term message queues. The design principle for messages: hold the encrypted blob until delivery, confirm delivery, and delete. The server is a post office that burns the letters after confirming receipt, not a filing cabinet.

After the move into Meta’s infrastructure around 2017-2019, persistent storage for media, profile data, and metadata almost certainly relies on Meta-internal systems – their distributed TAO store, their blob stores. That’s inference; the specifics aren’t public.

The Message Protocol

A lot of articles describe WhatsApp as “XMPP-based.” That’s technically true in the way that saying a heavily modified ship design is “inspired by the original blueprints.” The protocol runs over a persistent TLS socket – not HTTP, not polling. The connection stays open between the client and the server, which is how the server can push a new message to your phone without it having to ask every few seconds.

After initial connection, the wire format is binary, not XML. The original XMPP XML was compressed away in early optimizations because XML overhead on 2G connections in 2009 wasn’t free.

The stanza types that matter: message (the encrypted blob going somewhere), receipt (delivery confirmations), presence (online/typing/last seen), and call signaling. Groups work through a fan-out model on the server side – the server sends the message to each group member individually.

The three tick states in WhatsApp are probably the most visible part of the delivery pipeline. Single tick: the server got your message. Double tick: it landed on the recipient’s device. Blue tick: they opened it – if they haven’t disabled read receipts, which a surprising number of people do. Each state is a separate receipt message traveling back through the same pipeline, and each tells you something different about where in the system your message actually is.

Push notifications on WhatsApp don’t carry message content. On iOS, they go through APNs; on Android, through Meta’s push infrastructure. What they carry is essentially a tap on the shoulder – “open the app, something’s there.” The client wakes up, reopens its TLS socket, and fetches the real payload over the encrypted channel. This separation matters: Apple and Google’s push infrastructure is outside WhatsApp’s encryption perimeter, so putting actual message content there would mean it could be read by those platforms. Keeping the payload in the socket keeps it inside the encrypted channel.

End-to-End Encryption: the Signal Protocol

In 2016, WhatsApp brought end-to-end encryption to all chats via the Signal Protocol. Open Whisper Systems, led by Moxie Marlinspike at the time, developed this protocol. It’s the same one Signal uses, and starting in 2023, Meta’s Messenger and Google Messages for RCS adopted it too. The full specification is public, which is actually part of why it’s trusted – it’s been formally analyzed by cryptographers who don’t work for any of these companies.

The key exchange: X3DH

The first problem end-to-end encryption has to solve is: how do two people who’ve never talked before agree on a shared secret, without that secret ever being transmitted anywhere? X3DH – Extended Triple Diffie-Hellman – is how the Signal Protocol handles this. Your device generates several key pairs when you install the app and registers the public halves with the server. When someone messages you for the first time, their client downloads those public keys and runs a specific sequence of Diffie-Hellman operations across them. The output is a shared secret that both sides can independently derive, but nobody else can – including WhatsApp’s servers, which only ever had the public keys. The math is designed so that knowing both people’s public keys isn’t enough to reconstruct the shared secret.

Forward secrecy: the Double Ratchet

A single shared secret that covers an entire conversation is a bad idea. If someone captures your encrypted messages over a few months and later gets hold of the key – through a device seizure, a legal demand, a breach – they can decrypt everything retroactively. The Double Ratchet algorithm generates a fresh encryption key for each message, preventing this. Pay attention to the word “double”: it describes a symmetric ratchet that advances with each message sent, and a Diffie-Hellman ratchet that kicks in when parties exchange new public keys – two interlocking mechanisms. 

The symmetric ratchet means each message key is thrown away after use. The DH ratchet means even if a current key is compromised, future messages recover privacy once new keys are exchanged – that property is called post-compromise security. Together, they give you both directions: past messages stay protected even if a current key leaks, and future messages are fine even if a past key was exposed.

Groups: Sender Keys

Running a Double Ratchet session for every participant pair in a 500-person group would mean encrypting each message 499 times. That’s not practical. Sender Keys is the solution: instead of a separate session per recipient, each sender has one symmetric key for the group and shares it once with all members. A message gets encrypted once by the sender. Each recipient uses the shared sender key to decrypt the message and pass it along. If someone joins or leaves the group, the sender key is rotated. This way, former members can’t read new messages, and new members only get keys for messages from when they joined, not before.

Multi-device E2EE

Before 2021, WhatsApp’s end-to-end encryption didn’t work like it does now. The web client needed your phone to do all the heavy lifting. You’d use your laptop, but the decryption and re-encryption happened on your phone. It had to be switched on and connected too. While this worked for a phone-focused service, it meant that the web version was easily broken and updates were tough.

Then came the multi-device feature in 2021. Now, each device, including phones and laptops, has its own unique keys. They all sign up independently using something called the Signal Protocol. This means when you send a message, it encrypts differently for each user’s device.

So, you no longer need your phone to receive or send messages from your computer. Each device handles its stuff individually, making things much easier and more reliable overall. The server routes all those copies simultaneously. Your laptop decrypts with its own keys; your phone decrypts with its own keys; the phone being asleep or off no longer matters. This sounds clean from a user perspective – and it is, but it required substantially rebuilding how key management worked underneath. It’s the kind of change that looks like a minor feature on the product changelog and represents months of cryptographic re-architecture in the codebase. Most system design write-ups from before 2022 describe the old relay model, which is no longer how it works.

The multi-device architecture also required solving the history problem. When you link a new device, that device has no message history. WhatsApp transfers recent history directly from phone to the new device, encrypted in transit, without the server having access to the plaintext. It looks simple from the user side – “syncing” – and represents a significant re-engineering of the key management layer underneath.

What E2EE doesn’t protect

Content is opaque to WhatsApp. Metadata isn’t. The server knows who messaged whom, at what time, from what IP, and on what device. Profile pictures, last-seen timestamps, group memberships. The graph of relationships is visible even when the messages aren’t. This is a real privacy limitation, and it’s one Signal the product handles better by collecting less metadata overall. Worth understanding if you’re making security claims for your own chat product.

What Happens When You Send a Message

Stepping through the actual path, with encryption at the right layer, here’s the WhatsApp message flow:

1. You type. The plaintext lives only on your device – it has not left yet.
   
2. The app derives the next message key from the Double Ratchet chain and encrypts the plaintext with AES-256. The encryption key is then wrapped in the Signal Protocol session state and discarded after use. Even if someone exfiltrated your session key right now, they couldn’t decrypt the next message.
   
3. The encrypted blob plus routing metadata (recipient identity, timestamp, message ID) is sent over your persistent TLS socket to a WhatsApp edge server. 
   
4. The edge server reads the routing metadata (not the content – it can’t) and checks whether the recipient has an active connection. If yes: push immediately. If not: queue in Mnesia or a persistent store for later delivery.
   
5. Your app receives a single tick – the server confirmed receipt.
   
6. The recipient’s device gets the encrypted blob over its socket, or a push notification wakes the device, and it opens its socket to retrieve the queued payload.
   
7. The recipient’s app decrypts the blob using its own Double Ratchet state. The advance receipt goes back to the server, then to you as a double tick.
   
8. If the recipient opens the message (and has read receipts on), a read receipt flows back – blue tick.
   
9. Server deletes the encrypted payload from the queue. From here on, message history lives only on the sender and recipient devices. The server holds nothing.

Three Lessons Every Chat Builder Can Take

If you are going to build a chat app, you can use the experience of those who built the best. Here are the three best practices WhatsApp devs gave us.

Pick a concurrency model that fits the workload before writing application code

Erlang’s actor model – millions of lightweight processes, one per connection. This allowed the small teams to run the project with hundreds of millions of users. The modern equivalents are Elixir (which runs on the BEAM), Go goroutines, or well-structured Node.js with a connection-aware proxy. Thread-per-connection in Java or Python doesn’t reach past a few thousand concurrent sockets per box without significant pain. You don’t need to evaluate this at 100,000 users – but you should make a deliberate choice rather than inheriting whatever framework default you started with, because migrating later is expensive. This way, you’ll create a scalable chat app without extra cost and effort in the future.

Design the server as a router, not a content store

WhatsApp’s server holds encrypted blobs it can’t read, routes them, and forgets. This is the architecture regulated industries actually want – healthcare, fintech, and legal. The server sees the envelope, not the letter. If you build with this model from the start, HIPAA and GDPR become dramatically simpler: your compliance scope is the metadata you retain, not the message content. Bolt-on encryption to a content-storing server is much harder to audit than a system designed to never have the plaintext.

Multi-device is an architecture decision, not a UI feature

In 2021, WhatsApp had to redesign the key management and history synchronization architecture. This enabled connecting a laptop or tablet as a peer device. It would have cost far less if the initial WhatsApp system design could support N number of devices, with each having its own identity key.

If you’re building chat for anything other than a phone-only use case, plan for multi-device now: per-device identity keys, encrypted history transfer between devices, presence that represents a user, not a session. Retrofitting it later is a real project.

When You Should Not Clone This Stack

A lot of “how to build a WhatsApp clone” articles suggest starting with Erlang and XMPP. That’s almost certainly wrong for your situation, and here’s why:

You will not have 150 billion messages per day on day one. Engineering for that scale before you know whether your product has traction is how teams burn six months on infrastructure and launch with a chat feature that looks like every other chat feature. Erlang is genuinely hard to hire for. If your team runs Python, Node, or Go, starting a new project in Erlang means on-call rotations and debugging sessions in a language most of the team can’t read under pressure.

Full end-to-end encryption also blocks features you might actually want – full-text search across message history, AI that can read and respond to conversation context, and moderation that inspects content. WhatsApp’s E2EE means its server can’t do any of those things. If you’re building a customer support tool, a marketplace with AI-assisted chat, or an enterprise platform where admins need audit access, full E2EE isn’t what you want. You want encryption at rest, encrypted transport, and access controls – not a cryptographic commitment to server-side blindness.

The biggest mistake teams make when studying WhatsApp’s architecture is treating the technology choices as prescriptions instead of solutions to a specific set of constraints. Erlang was right for WhatsApp’s constraints. The Signal Protocol was right for their privacy position. Your constraints are probably different.

Build Your Own Without Rewriting the Plumbing

The three principles worth keeping from WhatsApp’s architecture – a concurrency model that fits the workload, server-as-router rather than content store, multi-device from day one – are already encoded in well-designed chat SDKs. You don’t need to write a BEAM scheduler to get them.

Ethora’s end-to-end encrypted chat SDK ships with persistent socket connections, offline message queues, delivery and read receipts, multi-device sync, and end-to-end encryption — the primitives that took WhatsApp’s team years to build correctly. Deploy it on your own infrastructure, and it’s your VPC, your encryption keys, your audit trail. 

The AI Bots SDK is where Ethora goes beyond what WhatsApp’s architecture allows. Because you control the encryption keys and can choose where in the pipeline AI features run, you can have AI-assisted chat that still meets compliance requirements – the AI processes content on your servers, within your perimeter, rather than sending messages to a third-party API. The React Native chat SDK covers iOS and Android from one codebase without platform-specific WebRTC and socket management.

So, if you’re ready to start building your WhatsApp clone, you can start right away, and for free. Ethora has everything you need to do that.