WhatsApp ticks: what they reveal about chat app design

Riya sends a message. First one grey tick, then two, then two blue. If an interviewer asks you to design a WhatsApp-like app, those ticks are a decent outline of the answer.

This is reverse engineering from the outside. No code, just the visible behavior, and a guess at the design behind it. What follows is a typical interview design, not WhatsApp's actual internals.

The answer that gets rejected

The obvious first idea is polling. Every phone asks the server every second, "message aaya?" Most of the time the answer is no.

Now picture a billion phones, a billion questions, every second. That's why this answer gets rejected. The ticks point to something better.

Following the message

Encryption on the phone. The message is locked on the sender's phone before it goes anywhere. The key lives only on the two phones. So the chat server sees only ciphertext, and WhatsApp doesn't read your messages.

An open connection. Think of a phone call that stays on. The phone keeps a line to the server open, so a message goes out immediately. No asking, no waiting for the next poll.

The chat server. This is just a computer in the middle. When the message reaches it, Riya gets one grey tick. That tick means one thing, the message reached the server.

The offline queue. If the friend's phone is off, the server holds the message in a queue, a waiting line. In the diagram it's held up to 30 days. The sender still sees one grey tick, because the server has it but the friend's phone doesn't.

The receipt. When the friend's phone comes on, the message arrives. The phone sends back a "got it" receipt. That's the second grey tick, so two grey ticks mean delivered.

Who gives the blue tick

The blue tick comes from the friend's phone. When the friend opens the chat, the phone sends a "read" receipt, and Riya sees two blue ticks.

WhatsApp didn't read anything. The server can't, since it only holds ciphertext. The blue tick is a receipt from a device, not an observation by the service.

So the full set of ticks is server, phone, read. Each one is an acknowledgement from a different hop in the chain.

Scaling the server

At peak, one chat server gets overloaded. The fix in the design is to add more servers. The open-connection model still works, because the work spreads across machines.

The design hangs together because every tick is a receipt from one specific step. If you can say which step each tick comes from, you've covered most of the design.

Next time you're asked about a chat app, don't start with polling. Walk through the ticks in order and name the component behind each one. The reel's question is a good one to answer out loud. Would you choose polling or an open connection, and why?