Lesson 10 of 30

WebSockets & Real-Time Data

Q: How would you build a live chat feature? Why WebSockets over polling, and what production concerns would you need to handle?

A strong answer covers: WebSockets provide a persistent, full-duplex connection — either side can push a message at any time, unlike fetch's strict request/response pattern; Polling/long-polling are real fallback techniques, but WebSockets fit a feature needing frequent, bidirectional, low-latency updates; Production concerns: explicit reconnection logic on drop, and awareness that WebSockets bypass typical HTTP tooling (caching, some proxies).

HTTP is a request, then a response, then the connection's job is done — WebSockets keep one connection open indefinitely so either side can send a message at any moment, which is what real-time features actually need.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

Why doesn't a plain fetch()-based request/response pattern fit a feature like live chat messages arriving from other users?

fetch can't receive server-initiated pushes — it only responds to a request the client madefetch requests are always too slow for real-time use casesfetch can only be used for GET requests, not for sending chat messages

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on WebSockets & Real-Time Data

What interviewers actually ask about this, and what a strong answer has to cover.

How would you build a live chat feature? Why WebSockets over polling, and what production concerns would you need to handle?

A strong answer covers

WebSockets provide a persistent, full-duplex connection — either side can push a message at any time, unlike fetch's strict request/response pattern
Polling/long-polling are real fallback techniques, but WebSockets fit a feature needing frequent, bidirectional, low-latency updates
Production concerns: explicit reconnection logic on drop, and awareness that WebSockets bypass typical HTTP tooling (caching, some proxies)

Likely follow-ups

What's the difference between WebSockets and Server-Sent Events, and when would SSE be the better fit?
How would you handle a user's connection dropping and needing to resume where they left off?
What load-balancing or infrastructure concerns come up with long-lived WebSocket connections at scale?

Practice these with the AI interviewer →

The plain-language idea

A normal fetch follows a strict pattern: the client asks, the server answers, done. For a live chat message, a stock price ticking, or a collaborative cursor moving, that pattern doesn't fit — the server needs to push data to the client the instant something happens, with no request to answer.

A WebSocket starts as a normal HTTP request, then upgrades to a persistent, full-duplex connection — both sides can send messages independently, at any time, over the same open connection, until either side closes it.

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

socket.onopen = () => socket.send(JSON.stringify({ type: "join", room: "general" }));
socket.onmessage = (event) => {
  const msg = JSON.parse(event.data);
  console.log("received:", msg);
};
socket.onclose = () => console.log("disconnected");

WebSockets: a connection that stays open both waysStep 1 of 3

HTTP: client asks, server answers, connection closes. To get updates, the client must keep asking (polling).

What people usually miss

Watch out

A dropped connection needs explicit reconnection logic — WebSockets don't automatically recover from a network blip; production code needs to detect onclose, wait (often with exponential backoff), and re-establish the connection and any necessary re-subscription.
This isn't the only real-time option. Server-Sent Events (SSE) are a simpler, one-directional (server-to-client only) alternative built on plain HTTP, well-suited to notifications/live feeds that never need the client to push data back over the same channel.
WebSockets bypass typical HTTP-layer tooling — caching, standard request/response logging, and some proxies/load balancers need explicit configuration to handle the protocol upgrade and long-lived connection correctly.

Why this matters in interviews

"How would you build a live chat feature?" is a great practical systems question, and correctly reaching for WebSockets (over polling, and knowing why SSE wouldn't fit a bidirectional chat) shows you understand the actual constraint — need vs. overkill — not just "there's an API for that."