WebSockets & Real-Time Communication

What is it?

A normal HTTP request only flows one way at a time: the client asks, the server answers, and the connection closes. That's a poor fit for things that need to feel instant and two-way — a chat message arriving, a live sports score updating, a multiplayer game move. WebSockets solve this by opening one long-lived connection between client and server that both sides can send messages over, at any time, without needing to start a new request each time.

Explain like I'm 10

A regular HTTP request is like sending a letter and waiting for a reply before you can say anything else. A WebSocket connection is like being on an open phone call — either person can speak up the instant they have something to say, without hanging up and redialing first.

Examples

A basic WebSocket exchange

// Client
const socket = new WebSocket("wss://chat.example.com");

socket.onmessage = (event) => {
  console.log("New message:", event.data);
};

socket.send("Hello from the client!");

// Server (conceptually) can push a message at any time,
// without the client having asked for it first:
// socket.send("New message from another user!");

How it works

A WebSocket connection starts as a normal HTTP request that asks to be "upgraded"; once the server agrees, the same underlying connection switches to WebSocket mode and stays open. From then on, both the client and the server can send messages over it at any time, in either direction, without the overhead of starting a brand new HTTP request for every single message.

Why does it exist?

Some experiences need the server to notify the client the instant something happens — a message arrives, a price changes, another player moves — rather than the client having to repeatedly ask "anything new yet?" WebSockets make that kind of real-time, two-way communication efficient, instead of relying on constant polling.

When to use it

Reach for WebSockets when you need frequent, low-latency, two-way communication — chat applications, live collaborative editing, real-time dashboards, multiplayer games.

When not to use it

For data that only changes occasionally, or where the client is fine checking every so often, a WebSocket's always-open connection is unnecessary overhead — a regular HTTP request (or an occasional poll) is simpler and doesn't require the server to hold open a persistent connection per client.

Common mistakes

• Reaching for WebSockets for data that barely changes, adding real infrastructure complexity (each open connection consumes server resources) with little benefit.

• Forgetting that a load balancer needs special configuration to keep a client's WebSocket connection routed to the same server for its whole lifetime.

• Not handling reconnection — a WebSocket connection can drop (network hiccup, server restart), and a robust client needs to detect that and reconnect.

Practice exercises

1. Easy:

   Explain, in your own words, why a chat app benefits from WebSockets more than a news website does.

2. Medium:

   Describe what 'polling' is, and how it compares to WebSockets for getting near-real-time updates.

3. Hard:

   Explain why a load balancer routing WebSocket traffic needs to behave differently than one routing regular HTTP requests.

Interview questions

What problem do WebSockets solve that plain HTTP doesn't?

They allow the server to push data to the client at any time over a single long-lived connection, instead of the client having to repeatedly ask for updates.

How does a WebSocket connection get established?

It starts as a normal HTTP request asking to 'upgrade' to a WebSocket; once the server agrees, the same connection switches to WebSocket mode and stays open.

When would a WebSocket be overkill?

For data that changes rarely, or where the client doesn't need updates instantly — a normal HTTP request (or occasional polling) is simpler and avoids holding open a persistent connection.