WhatsApp System Design
One Write vs 1024 Writes
5 min read
One of the most common system design interview questions is:
If you send a message to a WhatsApp group containing 1024 members, does the server perform 1 database write or 1024 database writes?
The answer depends on the architecture.
Let's explore the most common production approach.
The Naive Design
One possible solution is to create a copy of the message for every member.
User A
ā
Write Message for User 1
Write Message for User 2
Write Message for User 3
...
Write Message for User 1024
This works.
But it has several disadvantages.
- The same message is duplicated 1024 times.
- Storage grows unnecessarily.
- Editing or deleting becomes expensive.
- More writes increase latency.
At small scale, this is acceptable.
At WhatsApp scale, it becomes costly.
A Better Design
Instead of storing the same message 1024 times, store it once.
The message contains something like:
Message ID
Conversation ID
Sender ID
Timestamp
Encrypted Payload
Instead of creating 1024 copies, the system stores only one logical message.
But How Does Everyone Receive It?
The group membership is stored separately.
Example
Conversation
conversation_123
Members
Alice
Bob
Charlie
...
1024 users
When a new message arrives, the delivery service simply asks
Who belongs to this conversation?
Then delivery begins.
Notice something important.
The encrypted payload is not duplicated in the pending message store for each member.
Only delivery happens for every recipient.
What Happens for Offline Users?
Suppose Bob is offline.
The delivery service cannot immediately push the message.
Instead, the server temporarily keeps the encrypted message until Bob reconnects.
Once delivery succeeds, temporary server-side storage is no longer needed for that purpose.
What About Local Storage?
Every recipient eventually stores the message locally.
On Android this is typically backed by SQLite.
That means if 1024 users receive the message,
there will eventually be 1024 local database writes.
However, these are client-side writes, not the logical server-side message write discussed in this chapter.
Fan-out on Delivery
Large messaging systems often use fan-out on delivery.
The delivery service is responsible for pushing the message to every recipient.
This is different from duplicating the message in the message database.
Why Is This Better?
Advantages
- One logical message
- Lower storage requirements
- Faster writes
- Easier editing
- Easier deletion
- Better scalability
The delivery workload scales independently from message storage.
Interview Notes
Interviewer:
Why not simply create 1024 copies?
Good answer:
Because storing duplicate data wastes storage and increases write latency.
A common production design is to store the encrypted payload once, identify recipients through conversation membership, and fan out delivery asynchronously.
Server-side storage here is for reliable delivery ā not permanent plaintext chat history. Devices keep the durable local copy after they receive the message.
Key Takeaways
ā One logical message write is a common production approach.
ā Group membership is maintained separately.
ā Delivery is independent of storage.
ā Offline users receive messages later from temporary server-side storage.
ā Local device databases eventually store their own durable copy.