Sticky Sessions vs Redis Adapter for Zero-Downtime Socket.IO Migration

Context

A small Socket.IO application runs on a single Node.js process behind a load balancer. The team plans a rolling deployment to a new version across two nodes without dropping active clients. The constraint is zero downtime for WebSocket and HTTP long-polling transports during the cutover window.

Trade-off

Sticky sessions (session affinity) keep each client pinned to the node that issued its session ID, satisfying the long-polling handshake requirement. This approach needs no external infrastructure but prevents node A from emitting to a client connected to node B. The Redis adapter (@socket.io/redis-adapter) enables cross-node broadcasts via pub/sub so any node can reach any client, yet it introduces a Redis dependency and does not migrate existing connection state — rooms, per-socket data, and authentication context are lost when a client reconnects to a different node.

Unresolved behavior

Socket.IO provides no built-in mechanism to transfer an in-flight connection's session state to another node during cutover. The application must decide whether reconnecting clients re-authenticate and rejoin rooms idempotently, and how to handle duplicate events if server-side handlers are not idempotent.

Which approach better fits a small team that wants minimal operational overhead while guaranteeing that no client loses room membership or experiences duplicate events during a rolling restart? Should the Redis adapter be adopted solely for cross-node emits, or can sticky sessions plus client-side reconnection logic suffice if the application makes rejoin idempotent?