A WebSocket is a communication protocol that provides a full-duplex (two-way) channel over a single connection between a client (like a browser) and a server. It enables real-time, interactive communication, making it ideal for applications where frequent and low-latency updates are necessary. Unlike traditional HTTP, which follows a request-response model where the client has to request data each time, WebSockets allow for continuous communication once the connection is established. Both the client and server can send and receive messages independently at any time during the connection.
The communication starts with a standard HTTP request from the client to initiate the WebSocket connection. This is called the handshake.
If the server accepts the handshake, the protocol is upgraded to WebSocket, and the connection becomes persistent.
Once connected, both the client and server can freely send and receive messages as events.
We need to add a real‑time chat widget to our Node.js app. How would you set up a WebSocket connection from the client and server?
If a client tries to connect but the server is down, what does the WebSocket handshake return and how would your code handle it?
What happens if the client sends a message larger than the default frame size?
Our notification service uses WebSockets, but we’re seeing occasional 'socket hang up' errors after a client reconnects. Walk me through how you’d debug this.
We want to broadcast a message to all connected users, but only a subset should receive it based on a room ID. How would you implement that in Node.js?
Explain why the connection might close unexpectedly when the server restarts, and how you’d mitigate it.
Design a scaling strategy for a Node.js WebSocket server handling 100k concurrent connections. Discuss load balancing, sticky sessions, and state sharing.
What are the performance implications of using per‑message compression (permessage-deflate) at high throughput, and how would you decide whether to enable it?
If you need to support fallback to long polling for older browsers, how would you structure the code to keep the API consistent?
Our platform is moving from a monolithic Node.js WebSocket server to a microservices architecture. How would you redesign the real‑time layer to maintain low latency and reliability?
Discuss the trade‑offs of using a managed service like AWS API Gateway WebSocket versus self‑hosted Node.js servers for a global product.
How would you ensure backward compatibility for existing clients while rolling out a new message protocol version across multiple teams?