Building a secure messaging system that keeps conversations private across billions of devices is one of the hardest problems in distributed systems. End-to-end encryption (E2EE) protects user privacy, but it creates a fundamental challenge: how do you add a new device to an account without breaking the encryption guarantees? This architectural decision determines whether users can seamlessly access their messages everywhere or face friction at every login.
Architecture Overview
A WhatsApp-like messaging system sits at the intersection of cryptography, distributed databases, and real-time communication. The core architecture consists of several interconnected layers: a message broker (handling real-time delivery), a persistent storage layer (storing messages and metadata), a key management service (distributing encryption keys), and client applications (mobile, desktop, web) that handle the actual encryption and decryption.
The key insight is separation of concerns. The server never sees plaintext messages because encryption happens entirely on the client. The server's responsibility is message routing, delivery guarantees, and maintaining the state of conversations. This means the infrastructure handles metadata like "who sent this message and when," but not the content itself. For groups and media sharing, you need additional components: a media service (storing encrypted files in object storage) and a group management service (handling membership changes and permissions).
The system must also support message synchronization across devices. When you log in on your laptop after using WhatsApp on your phone, the new device needs to retrieve all previous messages and stay in sync with incoming ones. This creates the E2EE challenge we'll explore next.
Design Insight: Adding a New Device
When a user adds a new device to their account, the system must grant that device access to the conversation history without compromising security. The solution uses an elegant pattern: the new device generates its own encryption keypair, and the existing device encrypts a copy of the conversation's session key using the new device's public key. This way, the new device can decrypt historical messages without the server ever handling unencrypted keys.
Here's the flow: your phone receives a notification that you've added a new tablet. Your phone asks your server, "What's the tablet's public key?" The server provides it. Your phone then encrypts a copy of each active conversation's session key with the tablet's public key and sends it to the server. When the tablet comes online, it downloads these encrypted key packages, decrypts them with its private key, and suddenly has access to message history. The server never knows the actual encryption keys. This design maintains end-to-end encryption guarantees while enabling device flexibility.
The tradeoff here is security versus convenience. WhatsApp implements additional verification mechanisms (like security numbers) so users can confirm devices haven't been compromised, but the core architecture solves the sync problem without sacrificing encryption.
Watch the Full Design Process
This is Day 43 of our 365-day system design challenge, and we visualized this entire architecture in real-time using AI-powered diagram generation. Watch how the system evolved as we asked probing questions about encryption, device management, and scale:
Try It Yourself
Want to design your own secure messaging system? Head over to InfraSketch and describe your system in plain English. In seconds, you'll have a professional architecture diagram, complete with a design document. Whether you're exploring encryption patterns, multi-device support, or media distribution, InfraSketch transforms your architectural thinking into visual designs instantly.
