Open In App

Designing Whatsapp Messenger | System Design

Last Updated : 12 Apr, 2025
Comments
Improve
Suggest changes
Like Article
Like
Report

Ever thought about how this widely-used messaging app actually works behind the scenes? This article is your guide to the system design of WhatsApp. From handling tons of messages to making sure your chats are secure, we'll explore the technical aspects that keep this app running smoothly and managing things like managing data, keeping your messages private, and the challenges of making sure your texts arrive lightning-fast.

Designing-WhatsApp-Messenger--System-Design

Requirements

The WhatsApp messenger design should meet below requirements:

Functional Requirement

  • Conversation: The system should support one-on-one and group conversations between users.
  • Acknowledgment: The system should support message delivery acknowledgment, such as sent, delivered, and read.
  • Sharing: The system should support sharing of media files, such as images, videos, and audio.
  • Chat storage: The system must support the persistent storage of chat messages when a user is offline until the successful delivery of messages.
  • Push notifications: The system should be able to notify offline users of new messages once their status becomes online.

Non-Functional Requirement

  • Low latency: Users should be able to receive messages with low latency.
  • Consistency: Messages should be delivered in the order they were sent.
  • Availability: The system should be highly available. However, the availability can be compromised in the interest of consistency.
  • Security: The system must be secure via end-to-end encryption. The end-to-end encryption ensures that only the two communicating parties can see the content of messages. Nobody in between, not even WhatsApp, should have access.
  • Scalability: The system should be highly scalable to support an ever-increasing number of users and messages per day.

Capacity Estimation

Storage Estimation:

100 billion messages are shared through WhatsApp per day and each message takes 100 bytes on average

  • 100 billion/day∗100 Bytes = 10 TB/day
  • For 30 days, the storage capacity would become the following:
  • 30∗10 TB/day = 300 TB/month

Bandwidth Estimation:

According to the storage capacity estimation, our service will get 10TB of data each day, giving us a bandwidth of 926 Mb/s.

  • 10 TB/86400sec ≈ 926Mb/s

Number of Servers Estimation:

WhatsApp handles around 10 million connections on a single server, which seems quite high for a server.

  • No. of servers = Total connections per day/No. of connections per server = 2 billion/10 million = 200 servers
  • So, according to the above estimates, we require 200 chat servers.

High Level Design (HLD) of WhatsApp Messenger

High-Level-Design-(HLD)-of-WhatsApp-Messenger

The following steps describe the communication between both clients:

  • User A and user B create a communication channel with the chat server.
  • User A sends a message to the chat server.
  • Upon receiving the message, the chat server acknowledges back to user A.
  • The chat server sends the message to user B and stores the message in the database if User B's status is offline.
  • User B sends an acknowledgment to the chat server.
  • The chat server notifies user A that the message has been successfully delivered.
  • When user B reads the message, the application notifies the chat server.
  • The chat server notifies user A that user B has read the message.

Data Model Design

Data-Model-Design

  • users: This table will contain a user's information such as name, phone number, and other details.
  • messages: This table will store messages with properties such as type (text, image, video, etc.), content, and timestamps for message delivery. The message will also have a corresponding chatID or groupID.
  • chats: This table basically represents a private chat between two users and can contain multiple messages.
  • users_chats: This table maps users and chats as multiple users can have multiple chats (N:M relationship) and vice versa.
  • groups: This table represents a group between multiple users.
  • users_groups: This table maps users and groups as multiple users can be a part of multiple groups (N:M relationship) and vice versa.

API Design

1. Send message

  • sendMessage(message_ID, sender_ID, reciever_ID, type, text=none, media_object=none, document=none)
  • This API is used to send a text message from a sender to a receiver by making a POST API call to the /messages API endpoint. Generally, the sender’s and receiver’s IDs are their phone numbers.

2. Get Message

  • getMessage(user_Id)
  • Using this API call, users can fetch all unread messages when they come online after being offline for some time.

3. Upload File

  • uploadFile(file_type, file)
  • We can upload media files via the uploadFile API by making a POST request to the /v1/media API endpoint. A successful response returns an ID that’s forwarded to the receiver.

4. Download Media File

  • downloadFile(user_id, file_id)
  • Fetches a media file based on the user and file ID.

Architecture

We will be using microservices architecture since it will make it easier to horizontally scale and decouple our services. Each service will have ownership of its own data model.

Low Level Design (LLD) of System Design

The Low-Level Design involves detailed interactions between components and the specific data flow within the system. Below are the specific technical interactions and components its .

Low-Level-Design(LLD)-of-WhatsApp-Messenger

1. WebSocket Server Connection

WebSocket is used for real-time communication between WhatsApp users. Each user’s device establishes a persistent WebSocket connection to the WebSocket server, allowing for real-time message delivery.

Responsibilities:

  • Maintain an open connection with each active (online) user.
  • Map users to a port assigned to them on the WebSocket server.
  • Notify users when they have a new message or event.

Components:

  • WebSocket Server: Each active device connects via WebSocket. A WebSocket server handles message delivery by sending messages to the respective ports. One WebSocket server can handle millions of connections simultaneously (up to 10 million concurrent connections per server).
  • WebSocket Manager: It manages the mapping between users and ports. Uses Redis as a data store to map each active user to a port.

How It Works:

  • When User A connects to the WebSocket server, the server assigns them a port.
  • The WebSocket Manager stores the mapping (userId → port) in Redis.
  • User B sends a message to User A, and the message is routed through the WebSocket server to the correct port assigned to User A.

APIs:

  • connectUser(userId, port) - Assigns a port to a user.
  • disconnectUser(userId) - Disconnects a user.
  • getUserConnection(userId) - Retrieves the user connection details.

2. Message Service

The Message Service handles the sending, storing, and retrieval of messages. It ensures that messages are persisted (in case of offline users) and delivered in order.

Responsibilities:

  • Store messages in a database (for offline users).
  • Acknowledge message delivery status (sent, delivered, read).
  • Retrieve messages when a user comes online.
  • Automatically delete messages after a configurable retention period.

Components:

  • Message Queue (FIFO): Messages are sent via a message queue to ensure they are delivered in the same order they were sent (FIFO). Kafka is used for message queuing, ensuring messages are stored and processed sequentially.
  • Mnesia Database: The database stores persistent messages. It serves as the data source for sending and receiving messages.

How It Works:

  • User A sends a message to User B via the WebSocket.
  • The Message Service stores this message in Mnesia if User B is offline.
  • Once User B comes online, the message is retrieved from Mnesia and sent to User B.

APIs:

  • storeMessage(message) - Stores messages in Mnesia.
  • getMessages(userId) - Retrieves messages for a given user.

3. Media Handling (Asset Service)

WhatsApp supports sharing media files such as images, videos, and audio. The Asset Service manages the upload, storage, and retrieval of these media files.

Responsibilities:

  • Handles media file compression and encryption on the device side.
  • Uploads and stores media in Blob Storage (e.g., S3 or Google Cloud Storage).
  • Ensures content deduplication by using hashes.
  • Delivers media file IDs to the message service for forwarding to the receiver.

Components:

  • Blob Storage (e.g., S3 or Google Cloud Storage): Stores media files. Each media file is stored with a unique ID and hash to avoid duplication.
  • CDN (Content Delivery Network): If the asset service detects high demand for certain media, it uses a CDN to deliver the file faster to users across different regions.

How It Works:

  • User A uploads a media file (e.g., an image).
  • The file is compressed and encrypted on the device.
  • The Asset Service stores the file in Blob Storage and generates a unique ID.
  • The media ID is sent to User B via the Message Service.
  • User B downloads the file from the Blob Storage using the media ID.

APIs:

  • uploadMedia(userId, mediaFile) - Uploads media and returns a media ID.
  • getMediaFile(mediaId) - Retrieves a media file using the media ID.

4. Group Message Handling

WhatsApp also supports group chats. The Group Service manages group data and facilitates message delivery to all users in the group.

Responsibilities:

  • Manages user groups, including user IDs, group IDs, statuses, etc.
  • Queries the MySQL database to get group data.
  • Utilizes Redis cache to speed up access to frequently requested group data.

Components:

  • MySQL Database: Stores group information such as group ID, name, and member list.
  • Redis Cache: Caches frequently accessed group data to reduce latency.
  • Kafka Topic: Each group is represented as a Kafka topic. When a user sends a group message, the Message Service publishes it to the relevant Kafka topic.

How It Works:

  • User A sends a message to Group X.
  • The Message Service sends the message to Kafka, where it is saved in the respective group topic.
  • The Group Service retrieves the member list for Group X and sends the message to each member.

APIs:

  • sendGroupMessage(groupId, message) - Sends a message to all users in the group.
  • getGroupUsers(groupId) - Retrieves all users of a group.

Approach to achieve the below system attributes

Non-functional Requirements

Approaches

Minimizing latency

  • Geographically distributed cache management systems and CDNs (e.g., Cloudflare) reduce the latency of media files and messages.

Consistency

  • Provide unique IDs to messages using Sequencer or other mechanisms
  • Use FIFO messaging queue with strict ordering

Availability

  • Provide multiple WebSocket servers and managers to establish connections between users
  • Replication of messages and data associated with users and groups on different servers
  • Follow disaster recovery protocols

Security

  • Via end-to-end encryption

Scalability

  • Performance tuning of servers
  • Horizontal scalability of services

Next Article

Similar Reads