WhatsApp's Architecture for Billions: A Message Router Approach
This article highlights a key architectural design choice by WhatsApp: operating primarily as a message router without long-term server-side message storage, a stark contrast to Facebook Messenger. It delves into WhatsApp's historical architecture, leveraging Erlang for massive concurrent connections, and its impressive scalability achievements from early on, handling millions of connections per server.
Read original on Dev.to #systemdesignThe Core Architectural Distinction: Stateless Messaging
Unlike many modern messaging platforms that store extensive message history on their servers (like Facebook Messenger with Cassandra), WhatsApp adopted a fundamentally different approach. The article reveals that WhatsApp primarily functions as a message router, not a long-term message storage solution. Messages are delivered to the recipient and then deleted from the server, placing the burden of message history on the user's device. This design significantly simplifies server-side storage requirements and operational complexity for historical data.
Why a Message Router?
- Privacy: Messages are not stored on WhatsApp's servers long-term, enhancing user privacy.
- Scalability: Eliminating the need to store and index billions of messages reduces database load, allowing the system to focus resources on message routing and real-time delivery.
- Simplicity: Fewer complex storage systems means a simpler overall architecture for a service handling massive real-time traffic.
Leveraging Erlang for Concurrency
WhatsApp's original architecture from 2009 was built using Erlang, a programming language renowned for its ability to build highly concurrent, distributed, and fault-tolerant systems. Erlang's actor model and lightweight processes are particularly well-suited for handling a vast number of simultaneous connections and routing messages efficiently, akin to a "giant telephone exchange."
Erlang's Niche in System Design
Erlang excels in systems requiring high availability, soft real-time characteristics, and concurrency, making it ideal for telecommunications, messaging, and distributed systems where individual failures should not bring down the entire system. Its "let it crash" philosophy is a powerful paradigm for building resilient services.