You send your friend a message.
Hey, reached home?
But...
Their phone is switched off.
No internet.
No Wi-Fi.
No mobile data.
Hours later, they turn their phone back on.
Within a second...
✓ Delivered
How did your message survive?
Did WhatsApp keep trying forever?
Not exactly.
Let's see what actually happens.
The Naive Approach
Imagine the sender's phone sends the message directly to the receiver.
Your Phone
│
▼
Friend's Phone
What happens if their phone is offline?
The message is lost.
Clearly, that won't work.
The Real Architecture
Instead, your phone sends the message to WhatsApp's servers.
Your Phone
│
▼
WhatsApp Servers
│
▼
Friend's Phone
The server becomes the temporary owner of the message.
If the receiver isn't online...
The server stores it.
Step 1 — Message Arrives
Suppose you send:
"Reached?"
Your phone sends something like:
{
"messageId": "msg_9283",
"sender": "Alice",
"receiver": "Bob",
"content": "Reached?",
"timestamp": 1721144400
}The server stores it in persistent storage.
Not your phone.
Step 2 — The Receiver Is Offline
The server checks:
Is Bob connected?
No
Instead of failing...
It marks the message as Pending.
Pending Queue
↓
msg_9283
Nothing is lost.
Step 3 — Device Comes Online
Hours later...
Bob opens WhatsApp.
His phone establishes a connection.
Phone
↓
Authentication
↓
Connection Established
The server immediately asks:
Any pending messages?
Yes.
The queued messages are pushed to the device.
Step 4 — Delivery Acknowledgement
Bob's phone receives the message.
Immediately it replies:
ACK
Only after receiving this acknowledgement does the server mark:
Delivered ✓
If no acknowledgement arrives...
The server keeps the message.
What If the Internet Drops Midway?
Imagine the server starts sending.
Halfway through...
Bob loses internet.
Without acknowledgements...
The server assumes delivery failed.
Later...
It retries.
This prevents messages from silently disappearing.
Why Every Message Has an ID
Every message carries a unique identifier.
msg_9283
Suppose the network retries the same message.
Without IDs...
Bob might receive:
Hello
Hello
Hello
Instead...
The phone checks:
Already received?
↓
Yes
↓
Ignore duplicate
This is called idempotency.
Message Status Explained
Those little ticks aren't just UI.
They represent different stages.
🕒 Sent
↓
✓ Delivered to Server
↓
✓ Delivered to Device
↓
✓✓ Read
Each step depends on acknowledgements from different parts of the system.
What If You Have Multiple Devices?
Imagine you're logged in on:
- Phone
- Tablet
- Desktop
The server tracks each device separately.
Message
↓
Phone ✓
Tablet ✓
Desktop Pending
When the desktop reconnects...
It receives the missing messages automatically.
Why Push Notifications Matter
Your phone isn't constantly asking:
Any messages?
Any messages?
Any messages?
That would waste battery.
Instead...
Services like:
- Firebase Cloud Messaging (Android)
- Apple Push Notification Service (iOS)
wake the app when new messages arrive.
The app then fetches the pending messages.
Interview Questions
Why not send messages directly between users?
Because users are frequently offline.
The server guarantees reliable delivery.
Why use acknowledgements?
They tell the server exactly which messages were received.
Without ACKs, messages could be lost.
Why give every message a unique ID?
To prevent duplicates during retries.
This makes message delivery idempotent.
Why doesn't the client keep retrying forever?
Phones disconnect, restart, or lose battery.
The server is the reliable component that stores and retries messages.
Final Thoughts
When you send a message, you're not talking directly to another phone.
You're handing it to a distributed messaging system whose job is simple:
Never lose the message, even if the other person disappears for hours.
Those tiny check marks hide queues, acknowledgements, retries, idempotency, persistent storage, and distributed systems—all working together so that one simple message eventually reaches the right person.