💬
✉️
📸
▶️
Loading…
Loading…
💬
Hey! Are you there?
Delivered ✓✓ · 500ms
Picture this: you send "Hey!" on WhatsApp. Your friend's screen lights up in under a second — no refresh, no lag, even on a shaky 3G signal. Behind that instant delivery is an architecture that must solve a deceptively hard problem.
The web was built on HTTP: you ask, the server answers. Chat is the opposite — the server needs to reach out to you the moment something arrives, even when you haven't asked for anything. HTTP alone cannot do this.
Request Flow
The first instinct: just poll
The simplest fix is polling — your app pings the server every few seconds: "Any new messages?" It works in a demo. It collapses at scale. 99% of those pings come back empty, and at a billion users that's 30 billion wasted requests per minute.
// Phone polls every 3 s:
GET /messages/new → { messages: [] } // empty
GET /messages/new → { messages: [] } // empty
GET /messages/new → { messages: ["Hey!"] } // finally
// 1B users × 20 polls/min = 20,000,000,000 req/minWhat WhatsApp actually needs
WhatsApp's real-time contract: every message delivered in under 500ms, to any of 1 billion users, on a slow connection, even if the recipient's phone momentarily goes offline. That demands the server push — not the client poll.
// The goal: send() → delivered ✓✓ in < 500ms // At 1B users with WebSocket: only active messages create traffic // vs polling: O(users × poll_rate) = constant massive overhead
Why We Need This
This is a systems problem, not a code problem. Over the next seven steps you'll build the full architecture from scratch — starting with a naive HTTP approach, adding persistent connections, a message service, queues, caching, offline handling, and finally durable storage.
Key Insight
The real challenge isn't sending a message — it's guaranteeing delivery to a moving target (a phone that goes online and offline) at billion-user scale with sub-500ms latency.
Overview