WebSockets — From Sending Letters to Making Phone Calls

HTTP = Sending Letters

With regular HTTP, the client sends a request and the server responds. That's it. Connection closed.

Client: "Any new messages?" → Server: "Nope"
(5 seconds later)
Client: "Any new messages?" → Server: "Nope"
(5 seconds later)
Client: "Any new messages?" → Server: "Yes! Here's one"

This is called polling — the client keeps asking "anything new?" over and over. It's wasteful. 90% of the time, the answer is "no."

WebSockets = Phone Call

With WebSockets, the client and server establish a persistent connection. Either side can send data at any time without asking.

Client: "Hey, let's keep this line open"
Server: "Sure, connected! 🤝"
...
Server: "New message from Priya!" (pushes instantly)
Server: "Rahul is typing..." (pushes instantly)
Client: "Send this message to Priya" (sends instantly)

No repeated asking. The server pushes data the moment it's available.

Real-World Examples

WhatsApp / Telegram

When someone sends you a message, you see it instantly. The server pushes it to your phone through an open WebSocket connection. No polling needed.

Live Cricket Score (Cricbuzz)

The score updates in real-time without refreshing the page. The server pushes every ball update through WebSocket.

Stock Market Tickers

Stock prices change every millisecond. WebSockets push price updates to your trading app in real-time.

Multiplayer Games

Every player's movement needs to be sent to all other players instantly. WebSockets enable this real-time sync.

When to Use What?

Use HTTP when:

• Request-response pattern (fetch user profile, submit form)

• Data doesn't change frequently

• Client initiates all communication

• Caching is important

Use WebSockets when:

• Real-time updates needed (chat, live scores, notifications)

• Server needs to push data to client

• High-frequency updates (stock prices, gaming)

• Two-way communication (collaborative editing)

The Handshake

WebSocket starts as an HTTP request, then "upgrades" to WebSocket:

Client → Server: "HTTP GET /chat (Upgrade: websocket)"
Server → Client: "101 Switching Protocols ✅"
--- Connection upgraded to WebSocket ---
Now both can send data freely 🔄

Scaling WebSockets

The challenge: WebSocket connections are stateful. If User A is connected to Server 1, and User B is connected to Server 2, how does A's message reach B?

Solution: Pub/Sub with Redis

User A (Server 1) sends message
  → Server 1 publishes to Redis
  → Redis notifies Server 2
  → Server 2 pushes to User B

Key Takeaway

HTTP is for request-response. WebSockets are for real-time, bidirectional communication. In system design interviews, mention WebSockets whenever the requirement includes "real-time," "live updates," or "instant notifications." It shows you understand the right tool for the job.