You open WhatsApp, type a message, and hit send. A single grey tick appears. You're on a train with no signal, but the message went through anyway. Or did it?
That single tick is the beginning of a surprisingly well-designed system. Understanding how it works gives you a clear mental model for building reliable mobile apps.
Why messaging apps need offline support
Most apps assume a stable connection. Messaging apps can't afford that assumption.
People use WhatsApp on the subway, in elevators, in rural areas, and on spotty hotel WiFi. If the app failed silently every time the connection dropped, it would be unusable.
Offline support is not a nice-to-have. It's what makes messaging feel reliable.
What happens when you send a message without internet
When you tap send with no connection, WhatsApp doesn't show an error. It stores the message locally and marks it as pending.
The flow looks like this:
You type a message and tap send
The app writes the message to local storage immediately
The message is added to an outgoing queue
The UI shows a clock icon (pending) or a single grey tick
The app waits for a connection to actually deliver it
From your perspective, the message was sent. From the server's perspective, it hasn't arrived yet.
Local storage and message persistence
WhatsApp stores messages in a local database on your device. On Android, this is typically an SQLite database. On iOS, it uses Core Data backed by SQLite.
Every message has:
A unique local ID
The content
The recipient
A timestamp
A delivery status
This local database is the source of truth for what you see in the chat. The server is where messages get routed and stored for delivery to the other person.
The key insight here is that the app never waits for the server before showing you the message. It writes locally first, then syncs in the background.
Message queueing on the device
The outgoing queue is a list of messages waiting to be sent. When the app detects a connection, it works through the queue in order.
A simple mental model:
Outgoing Queue
--------------
[msg_001] → pending
[msg_002] → pending
[msg_003] → pending
Connection restored →
[msg_001] → sent to server → delivered
[msg_002] → sent to server → delivered
[msg_003] → sent to server → delivered
The queue preserves order. Messages arrive on the other end in the sequence you sent them, even if they were queued for minutes.
The queue also survives app restarts. It's persisted to disk, not held in memory. If you force-close WhatsApp and reopen it, the pending messages are still there waiting to go out.
Syncing messages when connectivity returns
When the connection comes back, a few things happen at once:
The outgoing queue flushes to the server
The app checks for incoming messages it missed
Delivery receipts are sent for messages received while offline
This sync happens in the background. You don't need to open the app for it to work. Background sync is handled by the operating system's background task APIs, which allow apps to run short tasks even when not in the foreground.
Delivery states: what the ticks actually mean
WhatsApp's tick system maps directly to the message lifecycle:
| State |
Indicator |
Meaning |
| Pending |
Clock icon |
Stored locally, not yet sent to server |
| Sent |
Single grey tick |
Received by WhatsApp's server |
| Delivered |
Double grey ticks |
Delivered to the recipient's device |
| Read |
Double blue ticks |
Recipient opened the chat and saw the message |
Each state is a confirmation from a different part of the system. The server confirms sent. The recipient's device confirms delivered. The recipient's app confirms read.
This is why you can see "delivered" even when someone hasn't opened the chat. Their phone received it, but they haven't looked at it yet.
Text messages are small. Media is not.
When you send a photo or video without internet, the app stores the media file locally and queues the upload separately from the message. When the connection returns:
The media file uploads to WhatsApp's servers
The server returns a media reference
The message is sent with that reference attached
The recipient's app downloads the media when they open the message
This is why you sometimes see a message arrive before the photo loads. The message and the media travel through different pipelines.
Large files also use chunked uploads. The file is split into smaller pieces, and each chunk is uploaded separately. If the connection drops mid-upload, only the failed chunk needs to retry.
Conflict resolution and message ordering
When multiple messages are sent offline and then sync at once, ordering matters.
WhatsApp uses timestamps to sort messages. Each message carries a client-side timestamp from when you tapped send. The server uses this to place messages in the correct order in the conversation.
This is a simplified version of what's called eventual consistency. The final state of the conversation is consistent across both devices, even if messages arrived out of order during sync.
In group chats, this gets more complex. Multiple people might send messages while offline, and all of them sync at different times. The server acts as the authority for final ordering.
Reliability and user experience considerations
A few things make this system feel reliable:
Messages are never lost once written to local storage
The queue retries automatically on reconnect
The UI reflects the real state of each message
Failed uploads surface clearly rather than silently dropping
The worst outcome is a message stuck in pending. That's visible. Silent failures are much harder to debug and much more frustrating for users.
WhatsApp also handles duplicate delivery. If a message is sent twice due to a retry, the server deduplicates it using the message ID. You don't end up with the same message appearing twice in the chat.
How offline-first architecture improves usability
Offline-first means the app works from local data by default and syncs with the server when possible. This is the opposite of online-first, where the app fails or shows errors when there's no connection.
Benefits of offline-first:
The app feels fast because it reads from local storage, not the network
Users can keep working without interruption
Sync happens in the background without blocking the UI
The app degrades gracefully on poor connections
This pattern is not unique to WhatsApp. It's used in apps like Notion, Figma, and Google Docs. Any app where losing work or losing access is unacceptable benefits from this approach.
Message state flow diagram
User taps send
|
v
Write to local DB
|
v
Add to outgoing queue
|
v
Show pending state (clock icon)
|
v
Connection available?
| |
No Yes
| |
| v
| Send to server
| |
| v
| Server ACK received
| |
| v
| Update to "Sent" (single tick)
| |
| v
| Recipient device receives
| |
| v
| Update to "Delivered" (double grey ticks)
| |
| v
| Recipient opens chat
| |
| v
| Update to "Read" (double blue ticks)
|
v
Queue persists, retries on reconnect
Common mistakes in offline messaging systems
Not persisting the queue across app restarts
Losing messages when the app is force-closed
Not handling duplicate delivery after a retry
Showing stale data without indicating it might be outdated
Blocking the UI while syncing
The queue must survive app restarts. If it lives only in memory, a crash wipes it. This is one of the most common mistakes in early implementations of offline-capable apps.
Short conclusion
WhatsApp's offline behavior is a well-designed queue, a local database, and a sync system that works in the background. The ticks are a window into that system. Understanding this pattern helps you build apps that feel reliable even when the network isn't.
