Web Sockets

💬 How WhatsApp Knows Exactly Where to Deliver Your Message (Even Behind a Wall of Servers)

Ever wondered how your "Hey, are you up?" message on WhatsApp magically reaches your friend?

Let’s decode the sorcery. 🧙♂️ (Spoiler: It’s not magic, it’s sockets.)

🔌 But First… What Even Is a Socket?

A socket is like a dedicated two-way tunnel between your app and the server. Unlike HTTP, which opens a connection, sends data, and closes it—WebSockets stay open, allowing continuous, real-time communication both ways.

Imagine opening a phone call that stays connected until you hang up. Now imagine millions of those calls happening across the globe, all in sync. That’s what WhatsApp and similar apps do—at scale.

📦 The Multi-Server Reality

In the world of scale, apps like WhatsApp aren’t running on just one server. They’re deployed behind something like an AWS Application Load Balancer (ALB), spreading the traffic across many identical instances of the backend app.

So here’s the puzzle:

• You send a message from Server A.
• Your friend is connected to Server B.
• The ALB doesn’t guarantee both of you land on the same server.

Then how does Server A know where your friend is? And how does it make sure the message gets there?

⚡️ The Power of Sockets

WhatsApp and similar apps use WebSockets, a persistent, bi-directional connection between client and server. Think of it as a dedicated hotline.

When you open WhatsApp:

1. Your app opens a socket connection to one of the backend servers.
2. That server keeps track: "Hey, this socket belongs to Prithvi."

Now multiply this by millions of users. Every server knows which users are connected to it.

🧠 Enter the Brain: Centralized State

Each server stores its local socket connections, but not everyone’s. So WhatsApp likely uses something like Redis or a centralized Pub/Sub system (like Kafka) to act as the brain of the operation.

Here’s what happens when you send a message:

1. i am connected to server A and i send a meessage to "Monika"
2. Server A says: "I have a message for Monika. Where’s Monika?"
3. It queries Redis and finds "Monika is connected to Server B."
4. Server A sends the message to Server B using a Pub/Sub or message queue.
5. Server B finds Monika's socket and delivers the message.

Boom. Delivered. ✅

🧵 Think of It Like This...

Imagine a massive office with hundreds of receptionists (servers). Each one handles calls (WebSocket connections) from different employees (users). When prithvi sends a message to Monika, your receptionist shouts across a connected intercom: "Hey, who's got Monika?"

Monika's receptionist answers: "Right here!" and delivers the message instantly.

This system keeps scaling as more people (users) and receptionists (servers) join. No one gets lost.

🧰 Tech in Play

Here’s a peek into what tech could be used behind the scenes:

• WebSockets – for real-time communication
• Redis Pub/Sub – to send messages across servers
• Node.js / Java / Go – backend languages commonly used
• Sticky Sessions (in some cases) – to keep a user on the same server (not always ideal)
• AWS ALB / NLB – load balancing between server instances

🎯 The Takeaway

Your message doesn’t travel through a straight line—it takes a clever, coordinated detour through a distributed system. Sockets make it real-time, Redis makes it connected, and architecture makes it reliable.

So next time you fire off that “wyd?” at 2 AM, just know: behind the scenes, a lot of engineering magic is happening to make sure it lands in the right chat.