Messaging Systems
WhatsApp Reliable Messaging
How messaging apps guarantee delivery even when you're offline — acknowledgements, retries, message ordering, and end-to-end encrypted delivery, explained simply.
How messaging apps guarantee delivery even when you're offline — acknowledgements, retries, message ordering, and end-to-end encrypted delivery, explained simply.
You send a message to a friend whose phone is switched off. A day later, they turn it on — and your message is right there waiting, in order, exactly as you sent it.
In plain terms: the system has to hold onto your message safely for however long it takes, prove to you at every stage what happened to it, never lose or duplicate it in a confusing way, and keep the contents private from everyone — including itself — the whole time.
Think of it like this: sending a message is like handing a sealed, tamper-proof letter to a postal worker who promises to keep trying delivery — today, tomorrow, next week — until it's placed directly in the recipient's hands, then reports back to you at every step.
Reliable messaging has to satisfy several things at once:
Recipients are offline all the time — the system can't assume anyone's connected.
A message, once sent, must never simply vanish — even across crashes or restarts.
Network retries can resend the same message — the system must recognize and dedupe them.
Messages in a conversation must display in the order they were actually sent.
Message content should be unreadable to anyone but the sender and recipient — including the server.
The system is a relay: a message is sealed on the sender's device, safely stored the moment it reaches the server, and patiently retried until it's handed off — with status reported back at every stage.
Composes the message, encrypts it on-device, assigns a unique local ID, and queues it for sending even if there's no connection yet.
In shortYour phone writes the message, locks it in an envelope only the recipient can open, and holds onto it until it can be sent.
Maintains a persistent connection per online device and authenticates each message before handing it off to the routing layer.
In shortThe front door that recognizes your phone the moment it comes online and accepts what it wants to send.
Every message is durably stored per recipient the instant it arrives — so it survives server restarts and can be delivered whenever the recipient reconnects.
In shortA safety-deposit box that holds your message the moment it's sent — even if the other person is offline for days.
Attempts delivery to the recipient's active devices, and automatically retries with backoff if a device is temporarily unreachable.
In shortKeeps knocking on the recipient's door every so often until someone answers — without giving up after one try.
Tracks server receipt, device delivery, and read status per message, and relays each status change back to the sender.
In shortThe system that turns delivery into those little grey, then blue, ticks you see on your screen.
Keys are exchanged directly between devices; the server only ever sees encrypted bytes, never the message content itself.
In shortThe server carries a locked box, but only the sender and recipient's devices hold the key to open it.
The message is encrypted on the sender's device using keys shared only with the recipient, then given a unique message ID.
In shortYour phone seals the message before it ever leaves your hand.
If there's no network, the message sits in a local outbox and is sent automatically the moment connectivity returns.
In shortNo signal? No problem — it waits patiently and sends itself the second you're back online.
The moment the server accepts the message, it's durably stored and a "server received" acknowledgement (one grey tick) is sent back to the sender.
In shortThe post office stamps "received" the second it takes your letter — that's the first tick.
The server tries to push the message to the recipient's device. If they're online, this typically happens in under a second.
In shortIt's handed straight to the recipient's phone if they're around.
Once the recipient's device confirms receipt, a second grey tick is sent back to the sender — the message has arrived, even if unread.
In shortThe letter is in their mailbox now — tick number two.
When the recipient actually opens the chat, a "read" event fires and the ticks turn blue on the sender's screen.
In shortThey've opened the envelope — ticks turn blue.
Those little ticks aren't just decoration — each one is a separate, real confirmation traveling back from a different stage of the journey:
Confirms the message left your device and reached the server successfully — it doesn't mean the other person has it yet.
In short"The post office has your letter."
Confirms the recipient's device has received and stored the message, even if they haven't opened the app.
In short"It's sitting in their mailbox now."
Confirms the recipient actually opened the conversation and viewed the message.
In short"They've read it."
A message that isn't acknowledged might have failed — or it might just be running late. A naive system risks losing messages or sending them twice; here's how production systems handle it instead:
In short: every message gets a unique ID the moment it's created. If a retry resends the exact same message, the recipient's device recognizes the ID and quietly ignores the copy — so "safe to repeat" beats "impossible to repeat."
Messages don't always travel the same path or arrive in the order they were sent — especially across flaky mobile networks. Ordering has to be actively enforced, not assumed:
Each conversation keeps its own running sequence number, so messages in that chat always render in the order they were actually sent.
In shortEvery chat has its own numbered ticket line — nobody can jump the queue within that chat.
If a later message arrives before an earlier one due to network timing, the client holds and reorders them using their sequence numbers before displaying.
In shortIf message #5 shows up before #4, the app quietly waits and puts them back in the right order.
Ordering is only guaranteed within a single conversation — there's no promise about the relative order of messages sent to two different chats at once.
In shortIt only promises order within one conversation, not across all your chats at once.
Modern messaging apps have to work across a phone, a tablet, and a linked web session — all while any of them might be offline at a given moment:
With billions of messages moving every day, the queueing and delivery layers are built to never lose data, even under heavy load:
| Layer | Common Choices |
|---|---|
| Client Transport | Persistent TCP/WebSocket connection per device |
| Message Queue | Durable per-user queues (Erlang/ejabberd-style or Kafka-backed) |
| Storage | Distributed key-value store for undelivered message spooling |
| Encryption | Signal Protocol-style end-to-end encryption (double ratchet) |
| Presence & Acks | Lightweight pub/sub for delivery and read-receipt events |
| Multi-Device Sync | Per-device session keys with a sync fan-out on send |
Reliable messaging looks like "just send a text," but it's really a store-and-forward distributed system juggling availability, ordering, deduplication, and privacy — all while feeling instant and effortless to the person tapping send.
A quick, no-nonsense translation of the technical terms used above.
Holding a message safely on the server until the recipient is available to receive it.
A small signal sent back confirming a message was received at some stage of its journey.
A guarantee that a message will arrive — even if that means it's occasionally delivered twice.
Safe to repeat — receiving the same message twice causes no duplicate or corruption, thanks to its unique ID.
A per-chat counter used to put messages back in the right order if they arrive out of sequence.
Only the sender and recipient's devices can read the message — not even the server in between.
Waiting a little longer between each retry attempt, instead of hammering the network immediately and repeatedly.
The system's knowledge of whether a device is currently online and reachable.