Design WhatsApp: System Design Interview Guide

WhatsApp is one of the most popular messaging apps globally, handling over 100 billion messages daily. Designing a system like WhatsApp is a classic system design interview question that tests your ability to build a real-time, scalable, and fault-tolerant application. In this guide, we'll walk through the key components, trade-offs, and interview strategies to ace this question.

Imagine you're asked: 'Design WhatsApp' in a 45-minute interview. The interviewer expects you to cover functional requirements (one-on-one chat, group chat, media sharing, online presence) and non-functional requirements (low latency, high availability, consistency, security). You'll need to propose a high-level architecture, dive into data models, discuss scaling strategies, and handle edge cases like offline messages or message ordering.

We'll start with requirements, then move to a deep dive on each component: WebSocket servers for real-time communication, Cassandra for message storage, Redis for presence, and CDN for media. We'll also cover end-to-end encryption, message delivery guarantees (at-least-once), and how to handle billions of users. By the end, you'll have a solid blueprint to impress any interviewer.

1. Requirements and Goals

Start by clarifying functional and non-functional requirements. Functional: send/receive messages (text, image, video), group chat (up to 256 users), online presence, delivery receipts (sent, delivered, read), media sharing, end-to-end encryption. Non-functional: low latency (<100ms for message delivery), high availability (99.999%), scalability (billions of users), consistency (messages ordered per conversation), security (encryption). Also consider offline messaging, multi-device support, and voice/video calls (optional).

2. High-Level Architecture

The architecture consists of clients (mobile/web), load balancers, chat servers (WebSocket), presence servers (Redis), message queues (Kafka), databases (Cassandra for messages, MySQL for user metadata), media storage (S3/CDN), and notification servers (APNS/FCM). Clients connect via WebSocket to chat servers for real-time messaging. Messages are persisted in Cassandra for durability. Presence is tracked in Redis with TTL. Media is uploaded to S3 and served via CDN. Notifications are sent via push when app is backgrounded.

3. Data Model

Key entities: User (userId, phoneNumber, displayName, avatarUrl), Message (messageId, conversationId, senderId, content, timestamp, type), Conversation (conversationId, participants, lastMessage, lastTimestamp), Media (mediaId, url, type, size). For one-on-one chat, conversationId = sorted(userId1, userId2) to ensure uniqueness. For group chat, conversationId is a UUID. Messages are stored in Cassandra with partition key = conversationId and clustering key = timestamp (for ordering). Example schema:

CREATE TABLE messages ( conversation_id text, message_id timeuuid, sender_id text, content text, media_url text, created_at timestamp, PRIMARY KEY (conversation_id, created_at, message_id) ) WITH CLUSTERING ORDER BY (created_at DESC);

CREATE TABLE messages (
  conversation_id text,
  message_id timeuuid,
  sender_id text,
  content text,
  media_url text,
  created_at timestamp,
  PRIMARY KEY (conversation_id, created_at, message_id)
) WITH CLUSTERING ORDER BY (created_at DESC);

CREATE TABLE users (
  user_id text PRIMARY KEY,
  phone_number text,
  display_name text,
  avatar_url text
);

CREATE TABLE conversations (
  conversation_id text PRIMARY KEY,
  participants list<text>,
  last_message text,
  last_timestamp timestamp
);

4. Real-Time Messaging Flow

When user A sends a message to user B: 1) Client A sends message via WebSocket to chat server. 2) Chat server assigns a unique message ID (timeUUID) and stores message in Cassandra. 3) Chat server pushes message to user B's WebSocket if B is online. 4) If B is offline, message is stored and later delivered via push notification. 5) Chat server sends acknowledgment back to A (sent receipt). 6) When B receives message, client sends delivery receipt. 7) When B reads message, read receipt is sent. All receipts are stored as special message types. For group chat, the server fans out messages to all group members (up to 256). For large groups, use multicast or separate queues.

import asyncio
import uuid

class ChatServer:
    def __init__(self, db, queue):
        self.db = db
        self.queue = queue

    async def handle_message(self, sender_id, conversation_id, content):
        message_id = uuid.uuid1()
        message = {
            'message_id': str(message_id),
            'sender_id': sender_id,
            'conversation_id': conversation_id,
            'content': content,
            'timestamp': int(time.time())
        }
        # Persist to Cassandra
        await self.db.insert_message(message)
        # Enqueue for delivery
        await self.queue.enqueue(message)
        # Send acknowledgment back to sender
        await self.send_ack(sender_id, message_id)

    async def deliver_message(self, message):
        # Get online users in conversation
        online_users = await self.presence.get_online_users(message['conversation_id'])
        for user_id in online_users:
            if user_id != message['sender_id']:
                await self.ws_send(user_id, message)

5. Presence and Online Status

Presence is tracked using Redis with a key 'presence:{userId}' and TTL (e.g., 30 seconds). Clients send periodic heartbeats (every 10 seconds) to refresh TTL. When a user connects, set presence to 'online'. When they disconnect (WebSocket close), set to 'last seen' timestamp. For privacy, users can configure who sees their status. Presence updates are broadcast to friends' online sessions via WebSocket. To scale, use Redis Cluster with sharding by userId. For millions of users, use Redis with read replicas and local caching on chat servers.

import redis
import time

class PresenceService:
    def __init__(self):
        self.redis = redis.Redis(host='localhost', port=6379, decode_responses=True)

    def user_online(self, user_id):
        self.redis.setex(f'presence:{user_id}', 30, 'online')

    def user_offline(self, user_id):
        self.redis.set(f'presence:{user_id}', f'last_seen:{int(time.time())}')

    def is_online(self, user_id):
        return self.redis.get(f'presence:{user_id}') == 'online'

    def get_last_seen(self, user_id):
        val = self.redis.get(f'presence:{user_id}')
        if val and val.startswith('last_seen'):
            return int(val.split(':')[1])
        return None

6. Media Sharing and Storage

Media (images, videos, documents) is uploaded directly to a CDN or blob store (e.g., S3) from the client. The client gets a pre-signed URL for upload. After upload, the media URL is sent as a message. For thumbnails, generate on the server side. Use CDN for fast global delivery. For large files, support chunked upload and resume. Media is encrypted at rest and in transit. To reduce storage costs, deduplicate media using hash (SHA256). For interview, mention using S3 with CloudFront CDN.

7. End-to-End Encryption

WhatsApp uses the Signal Protocol for end-to-end encryption. Each user has a public/private key pair. When two users chat, they exchange public keys and establish a session key using the Double Ratchet algorithm. Messages are encrypted with AES-256. The server never has access to plaintext. For group chats, each message is encrypted per recipient (sender keys). In an interview, you don't need to implement the protocol, but explain the concept: keys are stored on client, server relays encrypted messages. Mention key distribution and verification (safety numbers).

8. Scaling and Performance

To scale to billions of users: 1) Horizontal scaling of chat servers with load balancers (e.g., HAProxy). 2) Shard databases: Cassandra partitions by conversationId; use consistent hashing. 3) Use CDN for media. 4) Asynchronous processing with Kafka for message delivery, presence updates, and analytics. 5) Caching: Redis for presence and session data; local caches for user metadata. 6) Geo-distributed data centers to reduce latency. 7) Use connection pooling and multiplexing on WebSocket. 8) For group chat fan-out, use a message broker with topic-based routing.

9. Fault Tolerance and Reliability

Ensure no message loss: 1) Persist messages before acknowledging. 2) Use replication in Cassandra (RF=3). 3) Kafka provides durability with replication. 4) WebSocket reconnection with exponential backoff. 5) Idempotent message delivery: clients deduplicate using messageId. 6) Graceful degradation: if database is slow, queue messages and deliver later. 7) Circuit breakers for external services (e.g., push notifications). 8) Regular backups and disaster recovery across regions.

10. Interview Tips and Common Pitfalls

Common mistakes: 1) Not clarifying requirements (e.g., group chat size). 2) Ignoring offline messaging. 3) Overcomplicating the design (e.g., microservices for everything). 4) Forgetting about encryption. 5) Not discussing trade-offs (e.g., consistency vs availability). Tips: 1) Start with a simple design and iterate. 2) Use whiteboard to draw architecture. 3) Mention numbers (e.g., 100B messages/day). 4) Discuss bottlenecks and how to address them. 5) Show you can think about edge cases (e.g., user blocking, message recall).