19 WebSocket & Socket.IO Interview Questions (2026)

Real-time interviews test more than low latency. A strong answer explains transport choice, authorization, ordering and delivery semantics, reconnection, backpressure, capacity, and what happens when a node or broker fails.

This guide covers WebSocket concepts and Socket.IO patterns that come up in backend and full-stack interviews.

Table of Contents

1. WebSocket Fundamentals Questions
2. Socket.IO Basics Questions
3. Rooms and Namespaces Questions
4. Authentication Questions
5. Scaling Questions
6. Error Handling Questions

WebSocket Fundamentals Questions

Understanding the WebSocket protocol is essential before diving into Socket.IO specifics.

What are WebSockets and how do they differ from HTTP?

WebSocket provides persistent, bidirectional message exchange after an HTTP-based opening handshake. Either peer can send text, binary, and control frames without creating a new HTTP request for each application message. HTTP is request-response, but modern HTTP can keep connections alive and multiplex streams, so “HTTP opens a new TCP connection for every request” is incorrect.

The common HTTP/1.1 handshake uses Upgrade: websocket; HTTP/2 can bootstrap WebSocket with extended CONNECT when the stack supports RFC 8441. Use wss: in production, validate Origin for browser clients, negotiate subprotocols deliberately, cap message sizes, and plan heartbeat, idle timeout, and backpressure behavior.

Key differences:

When should you use WebSockets vs HTTP polling?

Short polling is simple and cache/proxy friendly but trades request overhead and update latency against implementation cost. Long polling holds a request until data or timeout. WebSocket keeps a bidirectional channel open, which reduces per-message HTTP overhead but adds connection capacity, proxy timeout, deployment, backpressure, and recovery concerns.

Choose from measured requirements: message direction and frequency, tolerated latency, intermediaries, client support, binary data, delivery semantics, fan-out, offline recovery, and operational capacity. Ordinary request-response APIs remain a good fit for CRUD and file transfer; do not force every real-time-looking feature onto one transport.

When would you choose Server-Sent Events (SSE) over WebSockets?

Server-Sent Events use a long-lived HTTP response carrying UTF-8 text from server to browser. EventSource reconnects automatically and supports event IDs for resume. SSE can be easier for one-way feeds and works through many HTTP stacks, but buffering proxies, timeouts, connection limits, authentication constraints, and server capacity still need testing.

Use SSE for primarily server-to-client text events where ordinary HTTP requests can carry client commands. Use WebSocket when both sides send frequent messages, binary frames matter, or one bidirectional channel simplifies the protocol. SSE is still a stateful, long-lived connection at the server; it does not become stateless merely because it uses HTTP.

Socket.IO Basics Questions

Socket.IO is the standard library for WebSocket-based communication in Node.js applications.

What is Socket.IO and why use it over raw WebSockets?

Socket.IO is an event protocol and library layered on Engine.IO. It is not wire-compatible with a plain WebSocket client. Socket.IO 4.x can use HTTP long-polling, WebSocket, and WebTransport depending on client/server configuration, and can upgrade transports during a session.

It adds reconnection, rooms, namespaces, acknowledgements, broadcasting, adapters, and optional connection-state recovery. Those conveniences add protocol and operational coupling. Choose it when clients can use Socket.IO and the semantics fit; choose raw WebSocket, SSE, WebTransport, or a broker-specific protocol when interoperability or different guarantees dominate.

How do you set up a basic Socket.IO server and client?

Setting up Socket.IO requires creating an HTTP server and attaching Socket.IO to it. The server listens for connection events and registers handlers for custom events. The client connects and can emit and receive events immediately.

This pattern forms the foundation of all Socket.IO applications. The server handles the connection lifecycle while both sides use the same event-based API for communication.

// server.js - Basic Socket.IO setup
const express = require('express');
const { createServer } = require('http');
const { Server } = require('socket.io');
 
const app = express();
const httpServer = createServer(app);
const io = new Server(httpServer, {
  cors: { origin: "http://localhost:3000" }
});
 
// Connection handler
io.on('connection', (socket) => {
  console.log(`Client connected: ${socket.id}`);
 
  // Listen for custom events
  socket.on('chat:message', (data, ack = () => {}) => {
    const parsed = messageSchema.safeParse(data);
    if (!parsed.success) return ack({ ok: false, code: 'INVALID_MESSAGE' });
 
    socket.broadcast.emit('chat:message', {
      senderConnectionId: socket.id, // use authenticated user ID in production
      text: parsed.data.text,
      timestamp: Date.now()
    });
    ack({ ok: true });
  });
 
  // Handle disconnection
  socket.on('disconnect', (reason) => {
    console.log(`Client disconnected: ${reason}`);
  });
});
 
httpServer.listen(3001);

// client.js - Browser side
import { io } from 'socket.io-client';
 
const socket = io('http://localhost:3001');
 
socket.on('connect', () => {
  console.log('Connected to server');
});
 
// Send a message
socket.emit('chat:message', {
  user: 'Alice',
  text: 'Hello everyone!'
});
 
// Receive messages
socket.on('chat:message', (data) => {
  displayMessage(data);
});
 
socket.on('disconnect', () => {
  console.log('Disconnected from server');
});

What is the difference between emit, broadcast, and to?

These three methods control who receives your messages, and confusing them is a common source of bugs. emit sends to a specific socket, broadcast sends to everyone except the sender, and to targets specific rooms.

Understanding these distinctions is crucial for building correct real-time features. Using the wrong method means messages either don't reach intended recipients or reach unintended ones.

// emit - Send to THIS socket only
socket.emit('event', data);
 
// broadcast - Send to ALL sockets EXCEPT this one
socket.broadcast.emit('event', data);
 
// to - Send to specific room(s)
socket.to('room1').emit('event', data);        // Excludes sender
io.to('room1').emit('event', data);            // Includes everyone in room
 
// Multiple rooms
io.to('room1').to('room2').emit('event', data);

Key insight: socket.to(room) sends to everyone in the room EXCEPT the sender. io.to(room) sends to everyone INCLUDING the sender. This distinction catches many candidates in interviews.

How do acknowledgments work in Socket.IO?

An acknowledgement is an application callback, not proof of durable or exactly-once processing. It can be lost after the server commits, causing a retry; the same event can therefore be processed twice when retry logic is enabled. Add a timeout, operation ID, idempotency record, validation, authorization, and durable transaction boundary for critical commands.

// Server
socket.on('order:create', async ({ operationId, orderData }, callback) => {
  try {
    const order = await createOrderIdempotently({
      operationId,
      userId: socket.data.userId,
      orderData
    });
    callback({ success: true, orderId: order.id });
  } catch (error) {
    logOrderFailure({ error, operationId, userId: socket.data.userId });
    callback({ success: false, code: publicOrderErrorCode(error) });
  }
});
 
// Client
socket.timeout(5000).emit('order:create', { operationId, orderData }, (err, response) => {
  if (err) {
    // Outcome may be unknown: retry with the same operationId or query status.
    return;
  }
  if (response.success) {
    console.log(`Order created: ${response.orderId}`);
  } else {
    console.error(`Failed: ${response.error}`);
  }
});

Rooms and Namespaces Questions

Rooms and namespaces organize connections for targeted messaging and feature separation.

What are rooms and how do you use them?

Rooms are server-side broadcast groups within one namespace. A client cannot directly join itself: an event handler may request membership, but the server must authorize the authenticated subject against the room, tenant, and current resource state before calling join().

A key feature of rooms is automatic cleanup—when a socket disconnects, Socket.IO automatically removes it from all rooms. You don't need to manually track room membership for cleanup purposes.

io.on('connection', (socket) => {
  // Join a room
  socket.on('room:join', async (roomId, ack) => {
    const reply = typeof ack === 'function' ? ack : () => {};
    if (!isValidRoomId(roomId) ||
        !(await canAccessRoom(socket.data.userId, roomId))) {
      return reply({ ok: false });
    }
 
    socket.join(roomId);
 
    // Notify others in the room
    socket.to(roomId).emit('room:user-joined', {
      userId: socket.data.userId,
      roomId
    });
 
    console.log(`${socket.id} joined room ${roomId}`);
    reply({ ok: true });
  });
 
  // Leave a room
  socket.on('room:leave', (roomId) => {
    socket.leave(roomId);
    socket.to(roomId).emit('room:user-left', { userId: socket.id });
  });
 
  // Send message to specific room
  socket.on('room:message', async ({ roomId, text }, ack) => {
    const reply = typeof ack === 'function' ? ack : () => {};
    if (!socket.rooms.has(roomId) || !isValidMessage(text)) {
      return reply({ ok: false });
    }
 
    io.to(roomId).emit('room:message', {
      userId: socket.data.userId,
      text,
      roomId,
      timestamp: Date.now()
    });
    reply({ ok: true });
  });
 
  // On disconnect, automatically leaves all rooms
  socket.on('disconnect', () => {
    // Socket.IO handles room cleanup automatically
  });
});

What are namespaces and when should you use them?

Namespaces are separate communication channels on a single Socket.IO connection. Each namespace has its own connection event, event handlers, and rooms. They're useful for separating logically different features within your application.

Think of namespaces as different "apps" running on the same Socket.IO server. A chat namespace handles chat-related events, while a notifications namespace handles notification events. This keeps code organized and prevents event name collisions.

// Server: Different namespaces for different features
const chatNamespace = io.of('/chat');
const notificationsNamespace = io.of('/notifications');
 
chatNamespace.on('connection', (socket) => {
  console.log('User connected to chat');
 
  socket.on('message', (data) => {
    chatNamespace.emit('message', data);
  });
});
 
notificationsNamespace.on('connection', (socket) => {
  console.log('User connected to notifications');
 
  // Only notification-related events here
  socket.on('mark-read', (notificationId) => {
    // Handle notification logic
  });
});

// Client: Connect to specific namespaces
const chatSocket = io('http://localhost:3001/chat');
const notifySocket = io('http://localhost:3001/notifications');
 
// These are distinct logical Socket instances, normally multiplexed
// over one shared Engine.IO connection to the same origin.
chatSocket.emit('message', { text: 'Hello' });
notifySocket.emit('mark-read', 'notification-123');

What is the difference between namespaces and rooms?

Namespaces and rooms both organize connections, but they serve different purposes. Namespaces separate logically different features and require explicit client connection. Rooms group users within a namespace and can be joined/left dynamically on the server side.

Use namespaces when you have distinct features with different event structures—chat vs notifications vs admin panel. Use rooms when you need to group users within a feature—different chat channels, game lobbies, or user-specific message targeting.

Authentication Questions

Securing WebSocket connections is critical for any production application.

How do you authenticate WebSocket connections?

Authenticate in Socket.IO middleware before registering application behavior, and reject disallowed browser origins during the Engine.IO handshake. CORS configuration affects HTTP long-polling but is not, by itself, WebSocket authorization. Prefer a server-side session in a Secure, HttpOnly cookie or a BFF; if the architecture uses an auth payload, keep credentials out of query strings and browser Web Storage.

A long-lived connection outlasts many authorization changes. Recheck token/session expiry, account disablement, membership, and resource policy at the required freshness boundary. Store only a minimal trusted identity in socket.data; socket.id is ephemeral and public, not an identity.

const ALLOWED_ORIGINS = new Set(['https://app.example.com']);
 
io.use(async (socket, next) => {
  try {
    const origin = socket.handshake.headers.origin;
    if (!ALLOWED_ORIGINS.has(origin)) throw new Error('forbidden origin');
 
    const session = await sessionStore.readFromCookie(
      socket.request.headers.cookie
    );
    if (!session?.userId || session.expiresAt <= Date.now()) {
      throw new Error('invalid session');
    }
 
    socket.data.userId = session.userId;
    next();
  } catch {
    next(new Error('Authentication failed'));
  }
});
 
io.on('connection', (socket) => {
  socket.join(`user:${socket.data.userId}`);
 
  socket.on('private-message', async ({ recipientId, text }, ack) => {
    const reply = typeof ack === 'function' ? ack : () => {};
    if (!isValidMessage(text) ||
        !(await canMessage(socket.data.userId, recipientId))) {
      return reply({ ok: false });
    }
 
    io.to(`user:${recipientId}`).emit('private-message', {
      from: socket.data.userId,
      text
    });
    reply({ ok: true });
  });
});

const socket = io('https://realtime.example.com', {
  withCredentials: true
});
 
socket.on('connect_error', (err) => {
  if (err.message === 'Authentication failed') {
    // Redirect to login
  }
});

How do you handle authorization for sensitive operations?

Authentication confirms who the user is; authorization determines what they can do. Even after a user connects, you must verify permissions for each sensitive operation. Never trust the socket ID or any client-provided data for authorization decisions.

Validate the event schema and size, rate-limit abusive senders, and check current server-side policy in each sensitive handler. A role copied into the socket at connect time may become stale after revocation or tenant changes. Design a way to disconnect or reauthorize active sockets when security state changes.

io.on('connection', (socket) => {
  // WRONG: Trusting client-provided data
  socket.on('admin:delete-user', async (targetId) => {
    // Anyone can call this!
    await deleteUser(targetId);
  });
 
  // Verify current server-side policy and make retries idempotent
  socket.on('admin:delete-user', async ({ operationId, targetId }, ack) => {
    const reply = typeof ack === 'function' ? ack : () => {};
    if (!(await policy.canDeleteUser(socket.data.userId, targetId))) {
      return reply({ ok: false, code: 'FORBIDDEN' });
    }
    await deleteUserIdempotently({ operationId, targetId });
    reply({ ok: true, targetId });
  });
});

How do you handle users connected from multiple devices or tabs?

When a user opens your app in multiple browser tabs or devices, each tab creates a separate socket connection with a different socket.id. To send messages to all of a user's connections, join each socket to a user-specific room.

This pattern ensures private messages, notifications, and user-targeted events reach all of a user's active sessions. When any tab connects, it joins the user's room. Messages sent to that room reach every connected tab.

io.on('connection', (socket) => {
  // Every connection for this user joins their personal room
  socket.join(`user:${socket.data.userId}`);
 
  socket.on('private-message', ({ recipientId, text }) => {
    // This reaches ALL tabs/devices for the recipient
    io.to(`user:${recipientId}`).emit('private-message', {
      from: socket.data.userId,
      text,
      timestamp: Date.now()
    });
  });
});

Scaling Questions

Scaling WebSocket servers presents unique challenges due to the stateful nature of connections.

How do you scale WebSocket servers horizontally?

Each connection terminates on one server, while users and rooms can span many servers. Socket.IO's Adapter forwards broadcasts and room operations between nodes; available adapters include Redis Pub/Sub, Redis Streams, MongoDB, Postgres, cluster, and cloud messaging variants. Choose from latency, durability, ordering, recovery support, topology, and failure behavior—not habit.

Keep durable domain state in a database or event log rather than treating adapter Pub/Sub or in-memory rooms as the source of truth. Capacity planning must include concurrent connections, messages and bytes per second, fan-out, compression CPU, file descriptors, memory per connection, reconnect storms, broker limits, and slow consumers.

// Problem: WebSocket connections are stateful
// User A on Server 1 can't receive messages from User B on Server 2
 
// Solution: Redis adapter for cross-server communication
const { createAdapter } = require('@socket.io/redis-adapter');
const { createClient } = require('redis');
 
const pubClient = createClient({ url: 'redis://localhost:6379' });
const subClient = pubClient.duplicate();
 
async function start() {
  await Promise.all([pubClient.connect(), subClient.connect()]);
  io.adapter(createAdapter(pubClient, subClient));
  httpServer.listen(3001);
}
 
start().catch((error) => {
  console.error('Adapter startup failed', error);
  process.exitCode = 1;
});
 
// Cross-node broadcast through Redis Pub/Sub
io.on('connection', (socket) => {
  socket.on('broadcast-message', (data) => {
    if (!isValidMessage(data)) return;
    io.emit('message', sanitizeMessage(data));
  });
});

When does Socket.IO need sticky sessions?

Sticky sessions are required when Socket.IO's HTTP long-polling transport is enabled because one Engine.IO session uses repeated HTTP requests that must reach the originating server. They are not required when clients are configured for WebSocket or WebTransport only, because the live transport is one persistent connection. Reconnection may land on any healthy node and should not rely on process-local domain state.

Cookie-based affinity is usually more predictable than client-IP hashing behind NATs and proxies. Ensure proxy idle/read timeouts exceed Socket.IO's pingInterval + pingTimeout, configure upgrade forwarding, health checks and draining, and test rolling deploys plus reconnect storms.

Key scaling requirements:

1. Load balancing - Affinity only when polling is enabled; graceful drain and correct proxy timeouts
2. Cross-node adapter - Match broadcast/recovery/durability needs; Redis Pub/Sub is not durable
3. External truth - Persist authorization and domain state outside the connection process
4. Capacity and failure tests - Slow clients, hot rooms, node/broker loss, reconnect storms, and backpressure

Socket.IO connection-state recovery is not supported by the classic Redis Pub/Sub adapter because Pub/Sub does not persist packets. The Redis Streams adapter supports it. Even with a compatible adapter, recovery can fail, so applications still need a full re-sync path.

Error Handling Questions

Robust error handling is essential for production real-time applications.

How do you handle disconnection and reconnection?

Socket.IO clients reconnect automatically with randomized backoff by default. That restores a transport, not necessarily application state or missed events. Socket.IO's optional connection-state recovery can temporarily restore socket.id, rooms, socket.data, and packets, but recovery is not guaranteed and adapter support varies.

Default event arrival is at most once. The client buffers emits made while disconnected, which can create a burst after reconnect; the server does not normally buffer missed events for a disconnected client. Critical flows need durable event IDs/offsets, idempotent command IDs, bounded retries, duplicate handling, and a full snapshot or replay fallback.

// Server: opt in to bounded recovery
const io = new Server(httpServer, {
  connectionStateRecovery: {
    maxDisconnectionDuration: 2 * 60 * 1000,
    skipMiddlewares: false,
  },
});
 
io.on('connection', async (socket) => {
  if (!socket.recovered) {
    // Re-authorize memberships and send a snapshot/events after client offset.
    await synchronizeClient(socket);
  }
});
 
// Client
socket.on('connect', () => {
  if (!socket.recovered) requestFullSynchronization();
});
 
socket.on('disconnect', (reason) => {
  console.log(`Disconnected: ${reason}`);
});

Do not let a client submit an arbitrary list of rooms to rejoin. Reconstruct membership from current server-side authorization. For ephemeral telemetry, use volatile events instead of building an unbounded offline queue.

How do you prevent memory leaks with WebSockets?

Leaks and overload often come from per-socket timers/listeners attached to external emitters, unbounded queues/caches, retained request objects, or slow consumers. Socket.IO automatically removes a disconnected socket from its rooms and its own listeners; clean up only resources your application created.

Avoid one userSessions[userId] = socket slot because a second tab overwrites the first and disconnecting either can delete the other. Prefer user rooms or a Map<userId, Set<socketId>>. Bound outbound buffers and message sizes, apply admission/rate limits, and monitor heap, event-loop delay, sockets, bytes, queue depth, drops, and reconnect rate.

io.on('connection', (socket) => {
  const onAccountUpdated = (event) => {
    if (event.userId === socket.data.userId) {
      socket.emit('account:updated', event.publicData);
    }
  };
  externalEmitter.on('account-updated', onAccountUpdated);
 
  const expiryTimer = setTimeout(() => {
    socket.disconnect(true);
  }, millisecondsUntilSessionExpiry(socket.data.sessionExpiresAt));
 
  socket.on('disconnect', () => {
    clearTimeout(expiryTimer);
    externalEmitter.off('account-updated', onAccountUpdated);
  });
});

How do you implement error handling for Socket.IO events?

Define an error contract per event and always bound the time a caller waits for an acknowledgement. Validate payloads before business logic, attach correlation and authenticated actor context to logs, map expected domain errors to stable public codes, and never send stack traces or internal exception text to clients.

io.on('connection', (socket) => {
  function registerEvent(name, schema, handler) {
    socket.on(name, async (rawPayload, ack = () => {}) => {
      try {
        const payload = schema.parse(rawPayload);
        const result = await handler(payload, socket.data.userId);
        ack({ ok: true, result });
      } catch (error) {
        logSocketFailure({ error, event: name, socketId: socket.id });
        ack({ ok: false, code: publicErrorCode(error) });
      }
    });
  }
 
  registerEvent('message:create', messageSchema, createMessage);
});
 
// Global error handler for connection issues
io.engine.on('connection_error', (err) => {
  console.error('Connection error:', err.code, err.message);
});

How do you send a message to all users except those in a specific room?

Socket.IO has a built-in exclusion operator. It composes with rooms and compatible multi-node adapters, avoids fetching every socket into the application process, and expresses the target set directly.

io.except('vip-room').emit('announcement', { text: 'Hello!' });
 
// Include only one room, then exclude another:
io.to('online-users')
  .except('do-not-disturb')
  .emit('announcement', { text: 'Hello!' });

Quick Reference

Common patterns:

• User-specific rooms: socket.join(\user:${socket.data.userId}`)`
• Private messages: io.to(\user:${recipientId}`).emit('message', data)`
• Room broadcasts: io.to(roomId).emit('event', data)
• Ephemeral data: socket.volatile.emit(...) may be dropped instead of queued
• Recovery: event IDs/offsets, idempotency, bounded retry, and snapshot fallback

Frequently Asked Questions

What are WebSockets and how do they differ from HTTP?

WebSocket is a message protocol and browser API for persistent, bidirectional communication after an HTTP-based opening handshake. Either peer can send text or binary messages without a new HTTP request. HTTP remains request-response but can reuse or multiplex connections, so the important distinction is the application communication model—not the false claim that HTTP opens one TCP connection per request.

What is Socket.IO and why use it over raw WebSockets?

Socket.IO is an event protocol and library built over Engine.IO transports; it is not a WebSocket implementation and is not wire-compatible with a plain WebSocket client. It adds reconnection, fallback transports, acknowledgements, rooms, namespaces, broadcasting, adapters and optional recovery. Choose it when those semantics fit; raw WebSocket or SSE may be smaller and more interoperable.

What are rooms and namespaces in Socket.IO?

A namespace is a logical channel with its own middleware, handlers, and rooms; clients normally multiplex namespaces over one shared Engine.IO connection. A room is a server-side broadcast group inside one namespace. Sockets can join many rooms, leave explicitly, and leave all rooms automatically on disconnect. Joining a room is an authorization decision, not proof of permission.

How do you authenticate WebSocket connections?

Authenticate before accepting application events, validate browser Origin, and attach a minimal trusted identity to socket.data. With Socket.IO, middleware can inspect an HttpOnly session cookie or auth payload; do not put credentials in URLs or Web Storage. Revalidate expiry or revocation when required, and authorize every event and room join against server-side resource and tenant state.

How do you scale WebSocket servers horizontally?

Each live connection terminates on one server, so multi-node Socket.IO needs an adapter or broker to forward cross-node broadcasts and an external source of durable application state. Sticky sessions are required when HTTP long-polling remains enabled, but not for WebSocket- or WebTransport-only clients. Adapter choice affects recovery, durability, ordering, failure modes, and operations; Redis Pub/Sub is only one option.

What happens when a WebSocket connection drops?

Socket.IO clients normally reconnect with randomized backoff, but recovery is optional and can fail. Default delivery is at most once: the client buffers emits while disconnected, the server does not replay missed events, and an in-flight event may be lost. Critical flows need event IDs, persistence, offsets, idempotent handlers, bounded retries, duplicate handling, and a full state re-sync fallback.

Sources

• RFC 6455: The WebSocket Protocol
• RFC 8441: Bootstrapping WebSockets with HTTP/2
• WHATWG WebSockets Standard
• MDN: Using server-sent events
• Socket.IO 4.x: How it works
• Socket.IO 4.x: Delivery guarantees
• Socket.IO 4.x: Connection-state recovery
• Socket.IO 4.x: Rooms
• Socket.IO 4.x: Namespaces
• Socket.IO 4.x: Using multiple nodes
• Socket.IO 4.x: Redis adapter
• OWASP WebSocket Security Cheat Sheet

Related Articles

• Complete Node.js Backend Developer Interview Guide - Comprehensive backend interview preparation
• Express.js Middleware Interview Guide - Middleware patterns that integrate with Socket.IO
• Authentication & JWT Interview Guide - Securing WebSocket connections with JWT
• Node.js Advanced Interview Guide - Event loop and async patterns underlying Socket.IO
• System Design Interview Guide - Scaling real-time systems