WebSocket Interview Questions

Common WebSocket interview questions covering when to use them, how they differ from other real-time approaches, and how they scale in production.

Q: What's the difference between WebSockets, HTTP polling, and Server-Sent Events? HTTP polling has the client repeatedly send ordinary requests (every few seconds) asking "anything new?" — simple, but wasteful and adds latency up to the polling interval. Server-Sent Events (SSE) let the server push a one-way stream of updates to the client over a single long-lived HTTP connection, but only the server can send — the client can't send data back over that same channel. WebSockets provide a full-duplex, persistent connection where both the client and server can send messages to each other at any time, making them the right fit when the client also needs to send frequent, low-latency messages (chat, multiplayer input), not just receive updates.

Q: Why is scaling WebSockets across multiple server instances harder than scaling a stateless REST API? Because a WebSocket connection is long-lived and pinned to whichever specific server instance accepted it — unlike a stateless HTTP request, no other server instance holds a reference to that socket. If a message needs to reach a client connected to a different instance than the one that received it, the receiving instance has no direct way to deliver it without some shared coordination mechanism.

Q: How do you solve the problem of a message needing to reach a client connected to a different server instance? With a pub/sub backplane — commonly Redis pub/sub. Every server instance publishes outgoing messages to a shared channel and subscribes to receive messages from every other instance; each instance then delivers incoming messages only to the clients it personally has connected. This decouples "which instance is this message from" from "which instance is the recipient connected to."

Q: When should you NOT use WebSockets? For the large majority of applications: standard CRUD operations (creating/reading/updating resources), infrequent updates where a periodic request or manual refresh is acceptable, and cases where only the server needs to push data one-way (better served by Server-Sent Events). WebSockets add real operational cost — persistent per-client connections, scaling complexity requiring a pub/sub backplane, reconnection handling — that isn't worth paying unless the feature genuinely needs frequent, low-latency, bidirectional communication.

Q: How does a WebSocket connection get established given that it starts as an HTTP request? The client sends a normal HTTP request with an Upgrade: websocket header; if the server supports WebSockets on that route, it responds with 101 Switching Protocols, and the same underlying TCP connection switches from HTTP framing to WebSocket framing from that point on — no new connection is opened for the upgrade itself.

Q: Since the browser's WebSocket constructor can't set custom headers, how do you authenticate the handshake? Common options: pass a short-lived token as a query-string parameter on the wss:// URL, rely on the browser automatically attaching a same-origin session cookie to the handshake request the way it would for any other request to that origin, or connect without credentials and send an explicit authentication message as the very first message once the socket opens, with the server holding the connection unauthenticated (and disconnecting it after a grace period) until that message arrives.

Q: A client's token expires 15 minutes into what turns out to be a 2-hour WebSocket connection. What actually happens? Nothing automatically — a WebSocket connection, once open, isn't re-checked against auth on every message the way each individual REST call is. The server has to explicitly track each connection's token expiry and either proactively close the connection (prompting a reconnect with a fresh token) or accept a "re-authenticate" message the client sends over the existing socket with a newly refreshed token, updating the connection's associated identity in place.

Q: Why do production WebSocket servers send ping frames if the connection already appears open? Because a connection can go "half-open" — one side's process crashes, a NAT device or mobile network silently drops the mapping, a laptop sleeps — without either endpoint receiving a proper close event, sometimes for many minutes until an OS-level TCP timeout eventually notices. An application-level heartbeat (ping/pong) proactively and quickly reveals that the other side is actually gone, instead of waiting on TCP itself to notice or waiting for the next natural application message that may never come.

Q: Why does client-side reconnection logic need exponential backoff and jitter instead of just retrying immediately? If a server restarts or has a brief outage, every one of its previously connected clients gets disconnected at roughly the same moment; reconnecting immediately means all of them hit the server again at once, right as it's trying to recover — a self-inflicted spike of load exactly when the server is least able to handle it. Exponential backoff spaces out retries over increasing intervals, and jitter (a small random offset) prevents clients from staying synchronized with each other across those retries.

Q: What does "sticky sessions" actually mean for a WebSocket load balancer, given that a connection stays on one TCP stream anyway? Once a WebSocket handshake completes, all of that connection's frames do stay on the same backend automatically — stickiness isn't needed within one already-established connection. It matters for what happens on the next connection: if a client reconnects (or if a transport with an HTTP-polling fallback like Socket.IO is in use), a load balancer with no session affinity can route it to a different backend instance than before, which is exactly the scenario the pub/sub backplane pattern is designed to make safe regardless of which instance a client lands on.