Designing Whatsapp Messenger | System Design

Designing WhatsApp involves building a scalable and highly available messaging system that enables real-time communication between millions of users. This article explains the complete system design of WhatsApp, covering its architecture, APIs, database design, scalability, and performance considerations.

• Learn how WhatsApp handles real-time messaging, media sharing, notifications, and user presence at scale.
• Understand the high-level architecture, low-level design, database choices, APIs, and techniques used to build a reliable messaging platform.

1. Problem Statement

We need to design a WhatsApp-like messaging system that enables users to communicate in real time while supporting millions of concurrent users. The system should be scalable, highly available, and capable of delivering messages with low latency.

• Users should be able to send and receive text messages, media files, and documents seamlessly.
• The system should ensure reliable message delivery, maintain user presence, and support communication even under heavy traffic.
• The design should focus on scalability, fault tolerance, data storage, and overall system performance.

2. System Requirements

Before designing the system, we need to identify its functional and non-functional requirements. These requirements define the expected features and quality attributes of the system.

Functional Requirements

Functional requirements describe the core features that the system must support.

• Users should be able to register, log in, and authenticate securely.
• Users should be able to send and receive one-to-one text messages in real time.
• Users should be able to share media files such as images, videos, documents, and voice notes.
• The system should display message delivery status (Sent, Delivered, Read).
• Users should be able to view the online/offline status and last seen of their contacts.
• The system should send push notifications for new messages when users are offline.

Non-Functional Requirements

Non-functional requirements define how well the system should perform under different conditions.

• Availability: The system should remain available with minimal downtime.
• Scalability: It should support millions of concurrent users and growing traffic.
• Reliability: Messages should not be lost and should be delivered reliably.
• Low Latency: Messages should be delivered with minimal delay.
• Consistency: Message order and delivery status should remain consistent across devices.
• Security: User authentication, authorization, and data transmission should be secure.

3. Capacity Estimation

Before designing the architecture, we need to estimate the expected traffic and storage requirements. These estimations help us choose the right infrastructure, database, cache, and scaling strategy.

Assumptions

3.1 Storage Estimation

Each message occupies approximately 100 Bytes, and around 100 billion messages are exchanged daily.

Daily Storage = 100 Billion × 100 Bytes

= 10 TB/day

For 30 days,

Monthly Storage = 30 × 10 TB

= 300 TB

Estimated Storage: 300 TB/month (excluding media files).

3.2 Bandwidth Estimation

Based on the daily storage requirement,

Bandwidth = 10 TB / 86400 seconds

≈ 926 Mb/s

Estimated Bandwidth: ~926 Mb/s.

3.3 Server Estimation

Assume a single chat server can handle 10 million concurrent connections.

Number of Servers = Total Connections / Connections per Server

= 2 Billion / 10 Million

= 200 Servers

Estimated Chat Servers: 200 Servers.

3.4 Requests Per Second (RPS) Estimation

To estimate the traffic handled by the system, we calculate the average number of requests processed every second.

Assume WhatsApp processes 100 billion messages per day.

Requests Per Second (RPS)

= 100 Billion / 86,400

≈ 1,157,407 requests/second

≈ 1.15 Million RPS

Estimated Traffic: The system should be capable of handling approximately 1.15 million requests per second, with the ability to support even higher traffic during peak hours.

Note: This is an average estimation. During peak usage, the actual Requests Per Second (RPS) can be significantly higher, so the system should be designed to handle traffic spikes efficiently.

4. High Level Design

The High-Level Design (HLD) describes the overall architecture of the WhatsApp system and explains how different components work together to provide a scalable, reliable, and low-latency messaging service.

Core Components

After the diagram, explain each component one by one.

• Client: The client represents the WhatsApp application running on mobile or web devices. It allows users to send messages, upload media, and receive real-time updates.
• API Gateway: The API Gateway acts as the single entry point for all client requests. It authenticates requests and forwards them to the appropriate backend services.
• Load Balancer: The Load Balancer distributes incoming requests across multiple application servers to prevent overload and improve system availability.
• Chat Service: The Chat Service processes incoming messages, stores them, and coordinates message delivery between users.
• Authentication Service: The Authentication Service verifies user identities and manages login sessions.
• Presence Service: The Presence Service maintains user online status, last seen information, and active connections.
• Notification Service: The Notification Service sends push notifications when recipients are offline.
• Media Service: The Media Service handles uploading, downloading, and managing images, videos, documents, and voice notes.
• Message Queue: A Message Queue enables asynchronous processing of messages, improving reliability and handling traffic spikes efficiently.
• Redis Cache: Redis stores frequently accessed data such as active sessions, recent chats, and online presence to reduce database load.
• Database: The database stores user information, chat metadata, and message records.
• Object Storage: Large media files are stored in object storage such as Amazon S3 instead of the primary database.

Request Flow

After explaining the components, describe how a message travels through the system.

1. User A sends a message.
2. The request reaches the API Gateway.
3. The Load Balancer forwards the request to a Chat Service instance.
4. The Chat Service validates the request and publishes the message to the Message Queue (Kafka).
5. A Message Consumer reads the message from Kafka and stores it in the Database.
6. If the recipient is online, the message is delivered immediately through the WebSocket Server.
7. If the recipient is offline, the message remains stored, and the Notification Service sends a push notification.
8. Once the recipient receives the message, the delivery status is updated in the database and synchronized across devices.

Data Flow

The data flow shows how messages and media move through different components of the WhatsApp system after a user performs an action.

• The client sends a request to the API Gateway, which authenticates and forwards it to the Chat Service.
• The Chat Service checks the Redis Cache for frequently accessed data such as active sessions and recent chats.
• The message is published to the Message Queue (Kafka) for asynchronous processing and reliable delivery.
• A Message Consumer processes the message and stores the chat data in the Database.
• Media files such as images, videos, and documents are stored in Object Storage, while only their metadata is saved in the database.
• If the recipient is online, the message is delivered immediately through the WebSocket Server; otherwise, it remains stored until the recipient comes online.
• After successful delivery, the message status (Sent, Delivered, Read) is updated in the database and synchronized across all the user's devices.

5. Technology Stack

Before designing the data model, it is helpful to identify the technologies used by different components of the WhatsApp system. The following technology stack is commonly used to build a scalable and reliable messaging platform.

6. Data Model Design

The data model defines how WhatsApp stores and manages users, chats, messages, and media. A well-designed schema ensures efficient data storage, quick retrieval, and supports scalability as the system grows.

• Identify the core entities required for messaging and media sharing.
• Define relationships between entities to maintain data consistency.
• Select the appropriate database model based on scalability and performance requirements.

Core Entities

The WhatsApp system consists of the following core entities:

• User: Stores user profile information and online status.
• Chat: Represents a conversation between users.
• Message: Stores message content, sender, timestamp, and delivery status.
• Media: Stores metadata of uploaded media files.

Database Selection

A combination of SQL and NoSQL databases can be used depending on system requirements.

• SQL Database is suitable for storing structured data such as user accounts and authentication information.
• NoSQL Database is better suited for storing chat messages because it provides horizontal scalability and high write throughput.
• Media files should be stored separately in Object Storage, while only their metadata is maintained in the database.

7. API Design

The API design defines how the client communicates with the backend services to perform operations such as authentication, messaging, media sharing, and chat management.

• Design REST APIs that are simple, scalable, and easy to consume.
• Use appropriate HTTP methods for different operations.
• Secure APIs using authentication mechanisms such as JWT or OAuth.

Authentication APIs

Chat APIs

Media APIs

Sample Request

POST/api/v1/messages

{

"chatId": "chat_123",

"senderId": "user_101",

"message": "Hello!",

"type": "text"

}

Sample Response

{

"messageId": "msg_567",

"status": "sent",

"timestamp": "2026-07-20T10:30:45Z"

}

8. Low Level Design

The Low-Level Design (LLD) describes the internal structure of the system by defining the key classes, their responsibilities, and their interactions. It helps organize the application into modular and maintainable components.

Core Classes

The WhatsApp system can be designed using the following core classes:

• User: Manages user profile information and online status.
• Chat: Represents a conversation between users.
• Message: Stores message content, sender, timestamp, and delivery status.
• Media: Handles media attachments associated with messages.
• Notification: Sends push notifications to offline users.
• ChatService: Processes messages and manages chat operations.

SOLID Principles

The WhatsApp system follows SOLID principles to keep the code modular, maintainable, and easy to extend.

• Single Responsibility Principle (SRP): Each class or service has a single responsibility. For example, the MessageService handles messaging, while the NotificationService is responsible only for sending notifications.
• Open/Closed Principle (OCP): New message types such as text, image, video, or document can be added without modifying the existing messaging logic.
• Liskov Substitution Principle (LSP): Different message types (TextMessage, ImageMessage, VideoMessage) can be used wherever a generic Message object is expected.
• Interface Segregation Principle (ISP): Services expose only the methods they require, preventing classes from depending on unnecessary functionality.
• Dependency Inversion Principle (DIP): High-level services depend on abstractions rather than concrete implementations, making it easier to replace components such as databases, caches, or message queues.

Design Patterns

The following design patterns can be used in the WhatsApp system:

9. Scalability & Performance

Scalability and performance ensure that the WhatsApp system can handle millions of concurrent users while maintaining low latency, high availability, and reliable message delivery.

• Caching: Redis Cache stores frequently accessed data such as user sessions, active WebSocket connections, and recent chats to reduce database queries and improve response time.
• Load Balancing: A Load Balancer distributes incoming requests across multiple servers, preventing overload and ensuring high availability.
• Database Replication: Database replication creates multiple copies of data to improve read performance and provide fault tolerance during server failures.
• Database Sharding: Sharding distributes chat data across multiple database servers, allowing the system to scale horizontally as the number of users and messages increases.
• Asynchronous Processing: Kafka or other message queues process message delivery, notifications, and background tasks asynchronously, reducing response time for users.
• Horizontal Scaling: Additional Chat Servers, WebSocket Servers, and Media Servers can be added dynamically to handle increasing traffic without affecting existing users.
• CDN: A Content Delivery Network (CDN) caches media files closer to users, enabling faster downloads of images, videos, and documents across different regions.
• Rate Limiting: Rate limiting prevents excessive requests from a single user or device, protecting the system from spam, abuse, and denial-of-service attacks.
• WebSocket Scaling: Multiple WebSocket servers can be deployed behind a Load Balancer to distribute millions of concurrent user connections.

10. Bottlenecks & Improvements

This section discusses the potential challenges the WhatsApp system may face at scale and the techniques used to overcome them while maintaining high availability and performance.

• Identify common bottlenecks that can affect system performance.
• Apply suitable techniques to improve reliability, scalability, and fault tolerance.

Common Bottlenecks

As the number of users and messages grows, the WhatsApp system may encounter several bottlenecks that can impact performance and availability.

• Single Point of Failure (SPOF): A failure in a single server can make the service unavailable. Use redundancy and failover mechanisms to eliminate SPOFs.
• Database Bottleneck: A single database server may struggle under heavy read/write traffic. Database replication and sharding help distribute the load.
• Cache Misses: Frequent cache misses increase database queries and response time. Optimizing cache policies improves performance.
• Message Queue Backlog: During traffic spikes, messages may accumulate in Kafka. Partitioning and additional consumers help process messages faster.
• WebSocket Connection Limits: A single server can support only a limited number of concurrent connections. Horizontal scaling distributes users across multiple WebSocket servers.

Possible Improvements

The following techniques can further improve the scalability, reliability, and overall performance of the WhatsApp system.

• Auto Scaling: Automatically add or remove servers based on traffic demand.
• Failover Mechanism: Redirect traffic to healthy servers if a service or database fails.
• Retry Mechanism: Retry failed message deliveries to improve reliability.
• Geo-Distributed Deployment: Deploy servers across multiple regions to reduce latency for global users.
• Monitoring & Alerting: Continuously monitor system health and trigger alerts for failures or unusual traffic patterns.