Why Session Loss Happens in Hash Load Balancing and How to Fix It

1. What Is Session Loss

Session is a mechanism that lets a system recognize multiple requests from the same user as belonging to one logical session, reducing repeated DB or remote service calls and improving performance.

When a load‑balancing strategy based on hashing (e.g., ip_hash ) is used, a user may be routed to server A initially and later to server B. If the session data is stored only in the memory of server A, the switch causes "session loss" and related issues such as cache miss, login state disappearance, and request failures.

The hash function maps a key (e.g., client IP) to a fixed server index. The diagram below shows a simple hash mapping:

With ip_hash , the expectation is that the same client IP will always be directed to the same server, allowing the session to stay in that server’s memory.

When a new server is added, the hash mapping changes, and a user may be sent to a different node, causing the session to disappear and forcing the system to fetch data from downstream databases or remote services, dramatically increasing latency and load.

This can cascade into a "butterfly effect" where the whole system becomes sluggish or even hangs.

2. How Nginx Solves the Problem

Nginx can use the nginx‑sticky‑module to implement session persistence. When a client first connects, Nginx assigns a server and writes a hashed identifier into a cookie. Subsequent requests containing that cookie are routed to the same server, achieving "sticky sessions".

If the client disables cookies, this method fails, but most modern browsers enable cookies by default.

3. Other Session‑Persistence Solutions

Besides sticky cookies, two additional approaches can achieve the same goal: Session Replication and Session Sharing .

3.1 Session Replication

The simplest method is to copy the session data from an existing node to any new node before it starts handling traffic, ensuring every node holds a full copy of each user’s session.

Advantages: high availability; a node can fail without losing sessions. Drawbacks: limited by each machine’s memory, requires continuous synchronization, and can cause bandwidth storms as the cluster grows.

3.2 Session Sharing

Store session data in a centralized shared storage (e.g., a database, distributed cache like Redis, or other NoSQL/NewSQL systems). All nodes read and write the same session record.

Advantages: no session loss regardless of node changes. Drawbacks: added network I/O and serialization overhead, plus the need to handle the storage’s single‑point‑of‑failure and maintenance costs.

The following chart compares the three solutions:

Session Persistence: the user stays on the original server.

Session Replication: every server holds identical session data.

Session Sharing: all servers use a single shared session store.

Large‑scale systems typically adopt Session Sharing because it can be horizontally scaled (e.g., using Redis clusters) to support virtually unlimited users.

4. Conclusion

While sticky sessions break the original intent of load balancing—distributing load evenly— they are a practical short‑term solution during early system stages. As the system grows, moving to a shared session store becomes the most robust approach.