IP Hash

IP Hash provides session persistence (sticky sessions) by guaranteeing that all requests from a specific client IP are routed to the same backend server for the duration of a session. This is critical for stateful applications where user session data is stored locally on a server.

• Mechanism: A hash function (e.g., MD5, SHA-1) is applied to the client's source IP address.
• Output: The hash output maps to a specific server in the pool.
• Result: The same client IP always produces the same hash, directing it to the same server.

Example: An e-commerce shopping cart application relies on IP Hash to ensure a user's cart items, stored in a server's local memory, remain accessible throughout their browsing session.

Unlike methods that track server connection counts, IP Hash enables the load balancer itself to remain stateless. The routing decision is made anew for each request based solely on the client IP, simplifying the load balancer's logic and reducing its memory footprint.

• No Session Table: The load balancer does not need to maintain a lookup table of client-to-server mappings.
• Pure Calculation: Each request is independently evaluated using the hash function.
• Scalability: This statelessness allows the load balancer to handle massive connection rates efficiently, as it performs a simple computation per request.

A significant limitation of IP Hash is its vulnerability to changes in the client's apparent IP address. This can lead to broken sessions and is a key consideration for deployment.

Common Causes of IP Change:

• Mobile Networks: A user switching from cellular to Wi-Fi.
• Corporate NAT/PROXY Pools: Outbound requests from a large organization may rotate through multiple public IPs.
• Load Balancer Chains: If traffic passes through multiple tiers of load balancers, the source IP seen by the final balancer may be the previous balancer's IP.

Consequence: The hash input changes, routing the client to a different server, which likely lacks their session state, causing errors.

IP Hash can lead to skewed load distribution across servers, as it depends on the randomness of incoming IP addresses. It does not account for server load or capacity.

Scenarios Causing Imbalance:

• Geographic Concentration: A large number of requests originating from a single corporate network (sharing a public IP) will all hash to the same server, overloading it.
• Non-Uniform Hash Ranges: Even with a good hash function, real-world IP address distribution is not perfectly uniform, leading to some servers receiving more traffic.
• Static Server Pool: The algorithm does not dynamically adjust for servers with different processing capabilities (unlike Weighted Least Connections).

Mitigation: Using a consistent hashing variant can improve distribution when servers are added or removed.

Implementing IP Hash involves configuring specific parameters on the load balancer to control its behavior and resilience.

Key Parameters:

• Hash Function: Choice of algorithm (e.g., src_ip, src_ip+port, src_ip+dst_ip+port). Using source port can help differentiate multiple connections from the same NAT device.
• Server Weight: Some implementations (e.g., NGINX's ip_hash) support weighted IP hash, where server weights are considered in the hash distribution.
• Failover Behavior: Definition of what happens when the target server is unhealthy. Typically, the hash is recalculated (using a modulus) to find the next available server, breaking session persistence.

Example NGINX Directive:

nginxCopy
upstream backend {
    ip_hash;
    server backend1.example.com weight=3;
    server backend2.example.com;
}

IP Hash is a specialized tool. Understanding when to use it versus other algorithms is crucial for system design.

Ideal for:

• Legacy Stateful Applications: Where session data cannot be easily externalized to a shared cache or database.
• Simple Persistence Needs: Environments with stable client IPs (e.g., internal corporate VPN access).
• Computational Efficiency: When the load balancer must make ultra-fast routing decisions with minimal overhead.

Consider Alternatives When:

• Client IPs are Unstable: Use cookie-based persistence (e.g., app_cookie, insert_cookie) for web applications.
• Server Load Varies: Use Least Connections or Least Response Time for optimal resource utilization.
• Dynamic Infrastructure: Use Consistent Hashing to minimize reshuffling when servers are added/removed frequently.
• Geographic Routing: Use Latency-Based Routing or GeoDNS to direct users to the nearest data center.

A distributed hashing technique that maps both servers and requests onto a hash ring. When a server is added or removed, only a small fraction of keys need to be remapped, minimizing disruption. This is critical for distributed caches and storage systems where session persistence is required but server pools are dynamic.

• Key Benefit: Provides stability during scaling events.
• Use Case: Foundation for systems like Apache Cassandra and DynamoDB.

A method where a load balancer directs all requests from a specific client session to the same backend server. This is often implemented using a cookie injected by the load balancer. While IP Hash provides a form of session persistence, dedicated sticky session mechanisms are more robust for clients behind proxies or NATs where IP addresses change.

• Mechanism: Cookie-based, SSL session ID, or custom header.
• Trade-off: Can lead to uneven load if sessions are long-lived.

A dynamic load balancing algorithm that directs a new request to the server with the fewest active connections at that moment. This is more responsive to real-time server load than static algorithms like Round Robin or IP Hash.

• Advantage: Efficiently accounts for varying request complexity and server capacity.
• Implementation: Requires the load balancer to maintain a real-time count of active connections to each backend.

A periodic test performed by a load balancer to verify a server instance is operational and capable of accepting traffic. Active health checks send synthetic requests, while passive health checks monitor the response to real client traffic. This is a foundational capability for any production load balancer to ensure traffic is only sent to healthy nodes.

• Types: TCP connect, HTTP GET, custom script.
• Critical Parameters: Check interval, timeout, success/failure thresholds.

A software design pattern used to detect failures and prevent an application from repeatedly trying to execute an operation that is likely to fail. In load balancing, this pattern can be implemented to temporarily stop sending traffic to a failing backend, allowing it time to recover.

• States: Closed (normal), Open (failing), Half-Open (probing for recovery).
• Purpose: Prevents cascading failures and enables graceful degradation.

Operates at the application layer (HTTP/HTTPS) of the OSI model. Makes routing decisions based on the content of the message, such as URLs, HTTP headers, cookies, or the message body. This enables advanced routing like content-based routing and API version routing, which are not possible with IP Hash (a Layer 3/4 technique).

• Capabilities: SSL termination, path-based routing, header manipulation.
• Example Systems: NGINX, HAProxy, AWS Application Load Balancer.