Advanced WebSockets with Socket.io — Patterns for Real-Time Apps

Your chat application works perfectly on localhost. In production with three Node.js servers behind a load balancer, messages sent by one user never reach another user on a different server. Socket.io's default in-memory adapter only works for a single process. Scaling real-time applications requires the Redis adapter, sticky sessions, or a different architecture entirely. This article covers the full journey from a single-process Socket.io server to a horizontally scaled real-time infrastructure, with production patterns for authentication, reconnection, and monitoring.

Why Raw WebSockets Aren't Enough for Production

Raw WebSockets provide a persistent, full-duplex communication channel, but they lack essential features for production real-time applications. Connection management, automatic reconnection, fallback transports, and room-based broadcasting are all missing. Socket.io builds on WebSockets with these features, but it's not a drop-in replacement—it introduces its own semantics and failure modes. In production, you need to understand the transport negotiation, the heartbeat mechanism, and how Socket.io handles scaling across multiple nodes. Without this, you'll face silent disconnections, memory leaks, and inconsistent state. This section sets the stage for why we choose Socket.io and what trade-offs we accept.

// Raw WebSocket server (Node.js ws library)
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });
wss.on('connection', (ws) => {
  ws.on('message', (data) => {
    // Broadcast to all clients
    wss.clients.forEach((client) => {
      if (client.readyState === WebSocket.OPEN) {
        client.send(data);
      }
    });
  });
});

// Socket.io equivalent
const io = require('socket.io')(3000);
io.on('connection', (socket) => {
  socket.on('message', (data) => {
    socket.broadcast.emit('message', data);
  });
});

Socket.io Architecture: Engine.IO, Transports, and Handshake

Socket.io is built on Engine.IO, which manages the transport layer. The handshake starts with an HTTP request to negotiate the best transport: WebSocket is preferred, but long-polling is used as fallback. Once established, Engine.IO maintains a heartbeat with ping/pong intervals. Socket.io adds the event-based messaging layer on top. Understanding this separation is crucial: Engine.IO handles connectivity, Socket.io handles application events. In production, you must configure pingInterval and pingTimeout to match your network conditions. Too aggressive and you'll drop connections unnecessarily; too lenient and you'll keep dead connections alive. Also, the handshake includes a session ID (sid) that persists across reconnections—this is how Socket.io restores state.

// Server-side Engine.IO configuration
const { Server } = require('socket.io');
const io = new Server({
  pingInterval: 25000,  // 25 seconds
  pingTimeout: 20000,   // 20 seconds
  transports: ['websocket', 'polling']
});

io.on('connection', (socket) => {
  console.log(`Client connected: ${socket.id}`);
  console.log(`Transport: ${socket.conn.transport.name}`); // 'websocket' or 'polling'
});

// Client-side
const socket = io('https://example.com', {
  transports: ['websocket'], // force WebSocket only
});

Rooms and Namespaces: Structuring Your Real-Time Channels

Socket.io provides two scoping mechanisms: namespaces and rooms. Namespaces are logical channels under the same connection (e.g., /chat, /admin). Rooms are sub-channels within a namespace (e.g., room: 'project-42'). Use namespaces to separate concerns (public vs. authenticated), and rooms to group sockets by context (e.g., a document being edited). Joining and leaving rooms is cheap, but beware of memory leaks: if you don't leave rooms on disconnect, stale references accumulate. Socket.io automatically leaves all rooms on disconnect, but if you have custom cleanup logic, ensure it runs. Also, avoid creating too many rooms dynamically—they are stored in memory. For massive scale, consider using an external adapter like Redis to share room state across nodes.

// Server: Namespace and room management
const io = require('socket.io')(3000);

const chatNamespace = io.of('/chat');

chatNamespace.on('connection', (socket) => {
  socket.join('general');
  
  socket.on('joinProject', (projectId) => {
    socket.join(`project:${projectId}`);
  });

  socket.on('leaveProject', (projectId) => {
    socket.leave(`project:${projectId}`);
  });

  socket.on('disconnect', () => {
    // Rooms are auto-leaved, but custom cleanup here
    console.log(`User ${socket.id} disconnected`);
  });
});

// Emit to a specific room
chatNamespace.to('project:42').emit('update', { data: 'new message' });

Middleware: Authentication, Rate Limiting, and Validation

Socket.io middleware runs on every connection and every event. Use it for authentication (verify JWT tokens), rate limiting (prevent event spam), and input validation. The middleware can reject a connection or an event by calling next(new Error(...)). For authentication, validate tokens in the handshake query or auth object. For rate limiting, track event counts per socket and use a sliding window. Be careful: middleware runs on the event loop, so heavy operations (like database queries) should be async. Also, middleware order matters—auth first, then rate limiting, then validation. In production, always have a fallback: if auth fails, disconnect the socket with a clear error message.

const io = require('socket.io')(3000);

// Authentication middleware
io.use((socket, next) => {
  const token = socket.handshake.auth.token;
  if (!token) {
    return next(new Error('Authentication required'));
  }
  try {
    const user = verifyToken(token);
    socket.user = user;
    next();
  } catch (err) {
    next(new Error('Invalid token'));
  }
});

// Rate limiting middleware per event
io.on('connection', (socket) => {
  const rateLimitMap = new Map();
  
  socket.use(([event, ...args], next) => {
    const now = Date.now();
    const windowMs = 1000;
    const maxEvents = 10;
    
    if (!rateLimitMap.has(event)) {
      rateLimitMap.set(event, []);
    }
    const timestamps = rateLimitMap.get(event);
    const recent = timestamps.filter(t => now - t < windowMs);
    if (recent.length >= maxEvents) {
      return next(new Error('Rate limit exceeded'));
    }
    recent.push(now);
    rateLimitMap.set(event, recent);
    next();
  });
});

Scaling Socket.io with Redis Adapter and Sticky Sessions

Socket.io out of the box works on a single process. To scale horizontally, you need an adapter (e.g., Redis) to broadcast events across nodes. The Redis adapter uses pub/sub: when one server emits an event, it publishes to Redis, and all other servers receive it and forward to their local clients. However, this introduces latency and potential message duplication. Also, because Socket.io uses long-polling as fallback, you must enable sticky sessions (or use a load balancer that supports it) to ensure a client's requests always hit the same server. Without sticky sessions, polling requests may go to different servers, breaking the connection. For WebSocket-only setups, sticky sessions are not required, but you still need the adapter for cross-server events.

const { createAdapter } = require('@socket.io/redis-adapter');
const { createClient } = require('redis');
const { Server } = require('socket.io');

const pubClient = createClient({ url: 'redis://localhost:6379' });
const subClient = pubClient.duplicate();

const io = new Server(3000, {
  adapter: createAdapter(pubClient, subClient)
});

io.on('connection', (socket) => {
  socket.on('chat message', (msg) => {
    // This will be broadcast to all nodes via Redis
    io.emit('chat message', msg);
  });
});

// Load balancer config (nginx) for sticky sessions
// upstream socket_nodes {
//     ip_hash;
//     server 10.0.0.1:3000;
//     server 10.0.0.2:3000;
// }

Handling Disconnections and Reconnection Strategies

Socket.io's automatic reconnection is a double-edged sword. It tries to reconnect with exponential backoff, but if the server is down, clients will keep hammering it. Configure reconnectionAttempts and reconnectionDelay to avoid a thundering herd. Also, on reconnection, the client gets a new socket ID, so you must restore state (e.g., rejoin rooms, re-authenticate). Use the 'reconnect' event to trigger re-initialization. On the server side, handle disconnection gracefully: save unsent messages, clean up resources, and notify other users. Beware of 'ghost' connections: if a client disconnects abruptly, the server may not detect it until the next ping timeout. Use 'disconnect' event with reason to differentiate between client-initiated and network loss.

// Client-side reconnection config
const socket = io('https://example.com', {
  reconnection: true,
  reconnectionAttempts: 5,
  reconnectionDelay: 1000,
  reconnectionDelayMax: 5000,
  randomizationFactor: 0.5
});

socket.on('connect', () => {
  console.log('Connected with id:', socket.id);
  // Rejoin rooms if needed
  socket.emit('restore', { lastRoom: 'general' });
});

socket.on('disconnect', (reason) => {
  if (reason === 'io server disconnect') {
    // Server intentionally disconnected, don't reconnect
    socket.disconnect();
  }
  // else, reconnection will happen automatically
});

// Server-side handling
io.on('connection', (socket) => {
  socket.on('restore', (data) => {
    socket.join(data.lastRoom);
  });
  
  socket.on('disconnect', (reason) => {
    console.log(`Socket ${socket.id} disconnected due to ${reason}`);
    // Clean up user presence
  });
});

Error Handling and Logging in Production

Socket.io errors can be silent. Uncaught exceptions in event handlers crash the process. Always wrap event handlers in try-catch and emit an error event back to the client. Use a centralized error handler that logs to an external service (e.g., Sentry, ELK). Also, monitor connection errors: failed handshakes, transport errors, and ping timeouts. Socket.io emits 'error' events on the server and client; listen to them. For logging, include socket.id, transport, and event name. In production, avoid logging full payloads—they can contain sensitive data. Instead, log metadata like event type and size. Also, set up health checks: a simple endpoint that checks if the Socket.io server is accepting connections.

// Server-side error handling
io.on('connection', (socket) => {
  socket.on('event', async (data) => {
    try {
      // Process event
      const result = await processData(data);
      socket.emit('result', result);
    } catch (err) {
      console.error(`Error processing event from ${socket.id}:`, err);
      socket.emit('error', { message: 'Internal server error' });
      // Log to external service
      logError(err, { socketId: socket.id, event: 'event' });
    }
  });
});

// Client-side error listener
socket.on('error', (err) => {
  console.error('Socket error:', err.message);
  // Show user-friendly message
});

// Global error handler for uncaught exceptions
process.on('uncaughtException', (err) => {
  console.error('Uncaught exception:', err);
  // Graceful shutdown
  io.close(() => process.exit(1));
});

Performance Optimization: Batching, Compression, and Backpressure

Real-time apps can generate high message throughput. To avoid overwhelming clients or the server, implement batching: combine multiple events into a single emit. Use compression (permessage-deflate) for WebSocket frames to reduce bandwidth. Socket.io supports per-message compression, but it adds CPU overhead—test with real traffic. Backpressure is critical: if a client is slow, the server's send buffer grows, leading to memory exhaustion. Socket.io provides 'drain' events and 'buffer' monitoring. Use 'socket.bufferedAmount' to check pending data. If it exceeds a threshold, consider dropping non-critical messages or slowing down the producer. Also, limit the number of listeners per event to avoid memory leaks.

// Server: batching and backpressure
const io = require('socket.io')(3000, {
  perMessageDeflate: {
    threshold: 1024 // Only compress messages > 1KB
  }
});

io.on('connection', (socket) => {
  const batchQueue = [];
  let batchTimer = null;
  
  socket.on('data', (msg) => {
    batchQueue.push(msg);
    if (!batchTimer) {
      batchTimer = setTimeout(() => {
        socket.emit('batch', batchQueue.splice(0));
        batchTimer = null;
      }, 100); // batch every 100ms
    }
  });
  
  // Monitor backpressure
  setInterval(() => {
    if (socket.bufferedAmount > 1024 * 100) { // 100KB
      console.warn(`Backpressure on ${socket.id}: ${socket.bufferedAmount} bytes`);
      // Optionally throttle or disconnect
    }
  }, 5000);
});

Testing Real-Time Behavior: Integration and Load Testing

Testing Socket.io apps requires special consideration because of the asynchronous, event-driven nature. Use the Socket.io client in tests to simulate real connections. For integration tests, connect a client, emit events, and assert responses. For load testing, use tools like artillery.io or k6 with WebSocket support. Focus on connection churn (many connect/disconnect cycles), message throughput, and reconnection scenarios. Also, test edge cases: server restart, network partition, and invalid payloads. In CI, run tests with both WebSocket and polling transports. Monitor memory usage and event loop lag during load tests. Set up alerts for high error rates or slow event processing.

// Integration test using Jest and socket.io-client
const { createServer } = require('http');
const { Server } = require('socket.io');
const Client = require('socket.io-client');

describe('Socket.io integration', () => {
  let io, serverSocket, clientSocket;

  beforeAll((done) => {
    const httpServer = createServer();
    io = new Server(httpServer);
    httpServer.listen(() => {
      const port = httpServer.address().port;
      clientSocket = new Client(`http://localhost:${port}`);
      io.on('connection', (socket) => {
        serverSocket = socket;
      });
      clientSocket.on('connect', done);
    });
  });

  afterAll(() => {
    io.close();
    clientSocket.close();
  });

  test('should receive echo', (done) => {
    clientSocket.on('echo', (msg) => {
      expect(msg).toBe('hello');
      done();
    });
    serverSocket.emit('echo', 'hello');
  });
});

Production Monitoring: Metrics, Alerts, and Debugging

In production, you need visibility into Socket.io's internals. Expose metrics: number of connected sockets, messages per second, transport distribution, and error rates. Use the 'connection' and 'disconnect' events to track active connections. For debugging, enable debug logging with environment variable DEBUG=socket.io:* — but be careful in production as it can flood logs. Use structured logging (JSON) to easily query logs. Set up alerts for sudden drops in connections (possible server crash) or spikes in errors. Also, monitor the Redis adapter's pub/sub latency. For debugging specific users, implement a 'debug' event that dumps socket state (rooms, transport, handshake). Never expose this in production without authentication.

// Expose metrics via a /metrics endpoint (Prometheus)
const prometheus = require('prom-client');

const connectedGauge = new prometheus.Gauge({
  name: 'socket_io_connected',
  help: 'Number of connected sockets'
});

const messagesCounter = new prometheus.Counter({
  name: 'socket_io_messages_total',
  help: 'Total messages processed',
  labelNames: ['event']
});

io.on('connection', (socket) => {
  connectedGauge.inc();
  
  socket.on('disconnect', () => {
    connectedGauge.dec();
  });
  
  // Increment counter on each event
  socket.use(([event], next) => {
    messagesCounter.labels(event).inc();
    next();
  });
});

// Expose metrics endpoint
app.get('/metrics', async (req, res) => {
  res.set('Content-Type', prometheus.register.contentType);
  res.end(await prometheus.register.metrics());
});

Security: Validating Input, Preventing Injection, and Rate Limiting

Socket.io applications are vulnerable to injection attacks if you don't validate input. Never trust client data: sanitize strings, escape HTML, and validate JSON schemas. Use a library like Joi or zod for validation. Also, prevent event injection: clients can emit any event name, so whitelist allowed events on the server. For authentication, use JWT tokens passed in the handshake auth object, not in query strings (which get logged). Implement rate limiting per socket and per IP to prevent abuse. For sensitive operations, require re-authentication. Also, be aware of Cross-Site WebSocket Hijacking (CSWSH): if your WebSocket endpoint doesn't check origin, an attacker's site can connect on behalf of a user. Use the 'origin' check or a CSRF token.

// Input validation with zod
const z = require('zod');

const messageSchema = z.object({
  text: z.string().max(500),
  room: z.string().regex(/^[a-zA-Z0-9_-]+$/)
});

io.on('connection', (socket) => {
  socket.on('chat message', (data) => {
    try {
      const parsed = messageSchema.parse(data);
      // Safe to use parsed.text
      io.to(parsed.room).emit('chat message', parsed.text);
    } catch (err) {
      socket.emit('error', { message: 'Invalid input' });
    }
  });
});

// Origin check
io.engine.on('initial_headers', (headers, req) => {
  const origin = req.headers.origin;
  if (origin && !origin.startsWith('https://yourdomain.com')) {
    headers['x-frame-options'] = 'DENY';
  }
});

Graceful Shutdown and Deployment Strategies

When deploying a new version, you need to disconnect existing Socket.io connections gracefully. Use the 'disconnect' event with a reason to inform clients. On the server, implement a shutdown hook: stop accepting new connections, notify clients to reconnect, and wait for existing connections to close. Use a process manager like PM2 with zero-downtime reload. For Kubernetes, use preStop hooks to drain connections. Clients should listen for the 'disconnect' event with reason 'io server disconnect' and then reconnect to the new server. Also, consider using sticky sessions with a load balancer that supports draining. Test your deployment process with a staging environment that mirrors production traffic.

// Server: graceful shutdown
const httpServer = require('http').createServer();
const io = require('socket.io')(httpServer);

process.on('SIGTERM', () => {
  console.log('SIGTERM received. Shutting down gracefully...');
  
  // Stop accepting new connections
  httpServer.close(() => {
    console.log('HTTP server closed.');
  });
  
  // Disconnect all sockets with reason
  io.disconnectSockets(true); // true = close underlying connections
  
  // Wait for all sockets to disconnect
  io.on('disconnect', (socket) => {
    if (io.engine.clientsCount === 0) {
      process.exit(0);
    }
  });
  
  // Force exit after timeout
  setTimeout(() => process.exit(1), 30000);
});

// Client: handle server disconnect
socket.on('disconnect', (reason) => {
  if (reason === 'io server disconnect') {
    // Server requested disconnect, reconnect manually
    socket.connect();
  }
});

RFC 6455 Protocol Internals: Upgrade, Frames, Opcodes, and Ping/Pong

WebSocket connections start with an HTTP upgrade request. The client sends a GET request with headers Upgrade: websocket and Sec-WebSocket-Key (a random 16-byte base64 value). The server responds with 101 Switching Protocols, Sec-WebSocket-Accept (SHA-1 hash of the key + magic GUID), and the connection upgrades to a full-duplex TCP socket. After upgrade, data is transmitted in frames. Each frame has an opcode: 0x1 (text), 0x2 (binary), 0x8 (close), 0x9 (ping), 0xA (pong). Text frames are UTF-8 encoded; binary frames are raw bytes. Ping frames trigger automatic pong responses—critical for keep-alive. Socket.io abstracts this, but understanding the wire protocol helps debug low-level issues. For example, a misconfigured proxy might strip the Upgrade header, causing a 200 response instead of 101. Always verify the handshake succeeds by checking the HTTP status code. In production, monitor ping/pong intervals to detect zombie connections. Socket.io's default pingInterval (25s) and pingTimeout (20s) can be tuned, but never exceed load balancer idle timeouts.

const WebSocket = require('ws');
const http = require('http');

const server = http.createServer();
const wss = new WebSocket.Server({ server });

wss.on('connection', (ws, req) => {
  console.log('Upgrade headers:', req.headers['sec-websocket-key']);
  ws.on('message', (data) => {
    // data is Buffer; check opcode via internal frame parsing
    console.log('Received frame type:', typeof data);
  });
  ws.on('ping', () => console.log('Ping received'));
  ws.on('pong', () => console.log('Pong received'));
});

server.listen(8080);

Connection State Recovery (Socket.IO 4.6+)

Socket.IO 4.6 introduced maxDisconnectionDuration to recover missed events after a temporary network outage. When a client reconnects within this window, the server replays buffered events and restores socket state (rooms, data). This is not magic—it requires the server to store events in memory (or Redis) for the configured duration. Default is 5 minutes. To enable, set connectionStateRecovery: true in the server options. The client must also opt-in by passing withCredentials: true (if using CORS) and a unique auth.token for identification. Internally, the server tracks a session ID and offset. On reconnect, the client sends its last received offset; the server replays events after that offset. This eliminates the need for manual event replay in many cases. However, it increases memory usage—each event stored for up to maxDisconnectionDuration. For high-throughput apps, consider reducing the duration or using a Redis adapter to offload storage. Also, state recovery only works for events emitted after the initial connection; it does not recover missed events from before the first connect.

const { Server } = require('socket.io');
const io = new Server({
  connectionStateRecovery: {
    maxDisconnectionDuration: 2 * 60 * 1000, // 2 minutes
  }
});

io.on('connection', (socket) => {
  console.log('Recovered?', socket.recovered); // true if state restored
  socket.on('chat message', (msg) => {
    io.emit('chat message', msg); // auto-buffered for recovery
  });
});

io.listen(3000);

Per-Socket Rate Limiting with socket.use()

Global rate limiting (e.g., per IP) is coarse. For finer control, use Socket.IO's socket.use() middleware to enforce per-socket rate limits. This function runs before every event handler. You can track event counts per socket using a simple in-memory map with timestamps. For distributed systems, use Redis with TTL. Example: allow max 10 events per second per socket. If exceeded, emit an error and disconnect. This prevents a single malicious or buggy client from flooding the server. Combine with socket.request to get IP for additional IP-based limits. Note: socket.use() does not catch internal events like connect; apply those in the connection handler. Also, be careful with async middleware—if you call next() asynchronously, ensure you handle errors. For production, use a library like rate-limiter-flexible with Socket.IO adapter. Remember to clean up rate limit data on disconnect to avoid memory leaks.

const rateLimit = require('rate-limiter-flexible');

const rateLimiter = new rateLimit.RateLimiterMemory({
  points: 10,
  duration: 1, // per second
});

io.use((socket, next) => {
  socket.use(async ([event, ...args], next) => {
    try {
      await rateLimiter.consume(socket.id);
      next();
    } catch (rej) {
      socket.emit('error', 'Rate limit exceeded');
      socket.disconnect(true);
    }
  });
  next();
});

Sticky Sessions for Load Balancers

Socket.IO uses long-polling as a fallback transport. Long-polling relies on HTTP cookies to maintain session affinity. Without sticky sessions, a client's subsequent requests may hit different servers, breaking the connection. Sticky sessions (also called session affinity) ensure all requests from a client go to the same server. For Nginx, use ip_hash or sticky directive. For AWS ALB, enable stickiness with a cookie duration matching your ping timeout. For HAProxy, use cookie SERVERID insert indirect nocache. Without sticky sessions, you'll see frequent disconnects and reconnections, especially during transport upgrades. Socket.IO's Redis adapter mitigates this for pub/sub, but the initial handshake and transport upgrade still require affinity. Always test with multiple nodes behind a load balancer. A common mistake is setting cookie timeout too short—set it to at least 24 hours. Also, ensure your load balancer supports WebSocket upgrades (e.g., Nginx proxy_http_version 1.1, proxy_set_header Upgrade).

upstream socket_nodes {
  ip_hash;
  server 10.0.0.1:3000;
  server 10.0.0.2:3000;
}

server {
  listen 80;
  location /socket.io/ {
    proxy_pass http://socket_nodes;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

Presence Tracking: Who's Online

Presence tracking shows which users are currently connected. Implement it by maintaining a set of online user IDs in a shared store (Redis). On connection, add the user; on disconnect, remove. For accuracy, handle multiple tabs: use a reference count per user. Socket.IO rooms can help: join each user to a personal room (e.g., user:${userId}). Then, to broadcast presence, emit to a global room. Use io.fetchSockets() to get all connected sockets, but beware of performance with many connections—use Redis to store presence data. Example: on connect, increment a Redis counter for the user; on disconnect, decrement; when counter reaches 0, remove. Also, emit 'user:online' and 'user:offline' events to a 'presence' room. For large apps, batch presence updates (e.g., every 5 seconds) to avoid flooding. Consider using Socket.IO's built-in socket.data to store user info, but for cross-server visibility, use Redis.

const redis = require('redis');
const client = redis.createClient();

io.on('connection', async (socket) => {
  const userId = socket.data.userId; // set by auth middleware
  const key = `user:${userId}:connections`;
  await client.incr(key);
  await client.expire(key, 86400); // expire after 24h
  
  const count = await client.get(key);
  if (count === '1') {
    io.to('presence').emit('user:online', userId);
  }
  
  socket.join('presence');
  
  socket.on('disconnect', async () => {
    const newCount = await client.decr(key);
    if (newCount <= 0) {
      io.to('presence').emit('user:offline', userId);
    }
  });
});

Graceful Shutdown Sequence

A graceful shutdown ensures no messages are lost and clients can reconnect without disruption. Steps: 1) Stop accepting new connections (close HTTP server). 2) Notify all connected clients that the server is shutting down (emit a 'shutdown' event). 3) Set a timeout (e.g., 10 seconds) for clients to acknowledge or disconnect. 4) Forcefully disconnect remaining sockets. 5) Close the Socket.IO server. 6) Close the HTTP server. Use process.on('SIGTERM') and SIGINT to trigger. In Kubernetes, the preStop hook should wait for the shutdown to complete. For Socket.IO, call io.close() which disconnects all sockets and stops the engine. If using Redis adapter, close the Redis client after. Important: set closeTimeout in Socket.IO options (default 5 seconds) to allow pending events to flush. Also, implement a health check endpoint that returns 503 when shutting down, so load balancers stop routing traffic.

const httpServer = require('http').createServer();
const io = require('socket.io')(httpServer, {
  closeTimeout: 10000, // 10 seconds
});

process.on('SIGTERM', async () => {
  console.log('Shutting down gracefully...');
  // 1. Stop accepting new connections
  httpServer.close();
  
  // 2. Notify clients
  io.emit('server:shutdown', { reconnectIn: 5000 });
  
  // 3. Wait for clients to disconnect or timeout
  await new Promise(resolve => setTimeout(resolve, 10000));
  
  // 4. Force disconnect
  io.disconnectSockets();
  
  // 5. Close Socket.IO
  await io.close();
  
  console.log('Server shut down');
  process.exit(0);
});

httpServer.listen(3000);