Understanding of Whatsapp Architecture

 Welcome to New Learnings Today...!

What I Learned from WhatsApp System Design

Today, I started exploring System Design by understanding how a messaging application like WhatsApp works behind the scenes.

Before learning system design, I mostly thought of messaging as something simple: I type a message, press send, and the other person receives it. But after looking at the system behind it, I realized that there are many things happening between these steps.

Here are the main things I understood today.

1. Sent, Delivered and Read

One of the first things I learned was that a message goes through different stages.

Sent

When I send a message, it first reaches the messaging service.

If the other person is offline, the message cannot be delivered to their device immediately. The system can keep the message until the recipient becomes available.

So, I understood Sent as:

The message has reached the messaging service, but it has not necessarily reached the recipient's device yet.

Delivered

When the recipient comes online and their device receives the message, it becomes Delivered.

So the flow is roughly:

Sender → Messaging Server → Recipient's Device

Read / Seen

Being delivered doesn't necessarily mean that the recipient has read the message.

When the recipient opens the chat and reads the message, a read receipt can be generated and sent back through the system.

So the overall flow I learned is:

Sent → Delivered → Read

These are separate events, and they don't necessarily happen at the same time.

2. Understanding Asynchronous Messaging

This was one of the concepts I found interesting.

In synchronous communication, the sender generally waits for the response before continuing that operation.

In asynchronous communication, the sender doesn't have to wait for the receiver to be available immediately.

For example, if I send a message to someone who is offline, I don't have to wait until they come online. The messaging system can accept and store the message and deliver it when the recipient becomes available.

This is related to the store-and-forward mechanism.

A simple way I understood it is:

Send → Store if necessary → Deliver when possible

This is important because users can be online or offline at different times, but the messaging system still needs to work reliably.

3. What Happens When the User Is Offline?

Suppose I send a message to a friend who has no internet connection.

The message can follow a flow like:

User A → Messaging Server → Temporary/Pending Storage → User B comes online → User B receives the message

This means the system needs to support offline message handling.

This also made me understand why a messaging application cannot depend on both users being online at exactly the same time.

4. Why NoSQL Can Be Useful

A messaging application can generate a huge amount of data because millions of users may continuously send messages.

A message can contain information such as:

• Message ID
• Sender ID
• Receiver ID
• Conversation ID
• Timestamp
• Message type
• Message status
• Media reference, if applicable

For a large-scale messaging system, a distributed NoSQL database can be useful because it can handle large volumes of data and support horizontal scalability.

 5. Text Messages and Media Are Different

Another thing that caught my attention was the difference between a normal text message and media.

For example:

"Hi, how are you?"

takes very little storage.

But an image, video, audio file or document can be much larger.

Imagine millions of users sending videos every day. The storage requirement would become enormous.

So I understood an important design idea:

Message metadata and actual media can be handled separately.

For example, the database can contain information such as:

messageId
senderId
receiverId
timestamp
messageType
mediaId

while the actual:

Image
Video
Audio
Document

can be kept in a separate media/object storage system.

The database basically tells us what the media is and where/how to find it, rather than having to treat a large media file like an ordinary text field.

6. Group Chat and the Fan-Out Problem

Group chat introduced another interesting problem.

Suppose User A sends one message to a group containing Users B, C, D and E.

The system now has to distribute one message to multiple recipients.

Conceptually:

User A → Messaging Service → B, C, D, E

This is called the fan-out problem.

As the number of group members increases, efficiently distributing the message becomes more challenging.

This made me realize that even a simple feature like "send a message to a group" can become a significant system-design problem when the number of users becomes very large.

7. What About Old Messages?

Another question I came across was: what happens if a conversation has thousands or even millions of messages?

It would not make sense to load the entire conversation every time the user opens the chat.

Instead, the application can use techniques such as pagination and lazy loading.

For example:

First load → 50 messages

Then, when the user scrolls:

Next → 50 messages

And so on.

This reduces the amount of data transferred and processed at one time.

8. Message Ordering

Another important problem is message ordering.

Suppose I send:

Message 1: Hi
Message 2: How are you?
Message 3: Where are you?

The recipient should ideally see them in the correct order.

In a distributed system, messages may travel through different components, so maintaining the correct order can become a challenge.

This introduces concepts such as:

• Timestamps
• Sequence numbers
• Message IDs
• Ordering guarantees

I haven't gone deeply into the implementation yet, but I understood why message ordering is an important problem in messaging systems.

My Key Takeaway

Before learning this, I saw WhatsApp simply as an application where one person sends a message and another person receives it.

Now I understand that behind that simple action there are many system-design challenges involving asynchronous communication, message persistence, delivery acknowledgments, NoSQL databases, media storage, fan-out, scalability, message ordering and fault tolerance.

I am still at the beginning of my System Design journey, but this was a good first step because I started understanding why these concepts are needed instead of just learning their definitions.

Next, I want to explore concepts like WebSockets, message queues, database partitioning and sharding, caching, and fault tolerance in more detail.

@Ramisetty Pavani