Understand Redis Adapter Limitations
The Redis adapter enables cross-instance broadcasting, but it does not solve every scaling problem.
Important considerations:
1. Sticky sessions
When HTTP long-polling is enabled and multiple Socket.IO servers are used behind a load balancer, sticky sessions are still required so requests belonging to one Engine.IO session reach the correct server.
2. Connection state recovery
The standard Redis adapter does not support Socket.IO connection state recovery. Do not assume that missed packets can always be restored after disconnection.
3. Redis availability
A Redis outage can affect cross-instance communication.
4. Local socket management
Each server still manages its own local sockets. Redis distributes adapter messages between instances.
5. Redis security
Protect Redis with authentication, ACLs, TLS where appropriate, and network restrictions.
For Redis 7.0 and newer, Socket.IO also provides a sharded adapter designed for Redis sharded Pub/Sub.
The Redis adapter handles inter-server event distribution. It does not remove the need for sticky sessions when using HTTP long-polling across multiple Socket.IO servers.
Socket.IO Scaling Options
| Feature | Default Adapter | Redis Adapter | Redis Sharded Adapter |
|---|---|---|---|
| Single instance | Yes | Yes | Yes |
| Cross-instance broadcasts | No | Yes | Yes |
| Redis required | No | Yes | Yes |
| Redis 7 sharded Pub/Sub | No | No | Yes |
| Connection state recovery | Supported | Not supported | Depends on implementation |
Redis adapter distributes events between instances.
Sticky sessions may still be necessary.
The standard Redis adapter does not support connection state recovery.
Redis infrastructure must be secured and monitored.