Introduction

In high-demand real-time applications like ride-hailing or booking platforms, maintaining a stable connection between the client and server is crucial.

Load balancing for WebSocket connections presents unique challenges, especially in routing the client to the same backend instance consistently.

Here, we’ll explore two effective solutions: IP-based sticky sessions and WebSocket routing via session identifiers, detailing their benefits, limitations, and practical applications.

Solution 1: Sticky Sessions Based on IP Address (IP Hash)

Overview:

Sticky sessions using IP hashing ensure requests from the same client IP are directed to the same backend server. This helps maintain session consistency by “sticking” a user to a particular instance, preserving session state across multiple requests.

Example Scenario:

Imagine a booking app like Uber, where users rely on real-time updates for driver locations and estimated arrival times. Using IP-based sticky sessions ensures that once a user connects to a server instance, subsequent updates and data are delivered consistently from the same instance, preventing session disruptions.

Steps to Implement:

1. Choose a Load Balancer: Use a load balancer that supports IP-based hashing (e.g., NGINX or HAProxy).
2. Configure IP Hashing: In the load balancer configuration, set the algorithm to hash based on client IP. This directs all requests from a specific IP to the same server.

upstream backend {
    hash $remote_addr consistent;
    server backend1.example.com;
    server backend2.example.com;
}

1. Test Connections: Ensure clients with static IPs experience consistent routing. However, test cases should include users with dynamic IPs, VPNs, or proxies to identify any potential session loss.

Benefits:

• Simple to implement with minimal overhead.
• Provides consistent routing for clients with static IPs.

Limitations:

• Can be unreliable for clients with dynamic IP addresses or those behind proxies/VPNs.
• IP address changes can disrupt session consistency, causing users to be routed to a different server.

Solution 2: WebSocket with Cookies or Session IDs

Overview:

This approach leverages session identifiers (IDs) or cookies to persist session state. With each WebSocket connection, the client sends a unique session ID, allowing the load balancer to route requests to the correct backend instance.

Example Scenario:

In a ride-hailing app, once a user initiates a connection to track their driver, a session ID is assigned. The load balancer uses this session ID to ensure all updates and real-time notifications come from the same server instance, avoiding reconnections or missed messages.

Steps to Implement:

1. Generate Session ID: When a user logs in or initiates a connection, generate a unique session ID. Store it in a cookie or include it as part of the WebSocket handshake request.
2. Configure the Load Balancer: Use a load balancer (e.g., HAProxy) capable of sticky routing based on custom headers or cookies.

backend websockets
    balance url_param session_id
    server backend1 backend1.example.com check
    server backend2 backend2.example.com check

1. Modify WebSocket Client Connection: Ensure the client includes the session ID in the WebSocket connection. This can be through cookies or URL parameters, depending on the setup.
2. Test Session Consistency: Verify that sessions remain connected to the same server and assess if reconnects maintain routing integrity through the session ID.

Benefits:

• Provides a more consistent connection compared to IP-based routing, especially for users on dynamic networks.
• Allows routing based on unique user session rather than IP, reducing the chance of session loss.

Limitations:

• Requires additional setup to manage session ID generation and validation.
• Slightly more complex to implement compared to IP-based routing.

Comparison of Both Methods

Conclusion

For WebSocket load balancing, both IP-based sticky sessions and session ID-based routing offer viable solutions, each with its strengths. IP hashing is quick to set up and works for users with static IPs, while session ID routing is more robust, especially in high-availability applications where consistent connection routing is critical. Consider your user base and application requirements to choose the method that best fits your needs.