When to Use Session Sharing vs. Session Persistence in Load‑Balanced Backends

Session sharing solves the problem of independent sessions across servers in a cluster, but it is not appropriate for all scenarios.

Typical cases where session sharing should be avoided include:

Closely related multiple interactions: In e‑commerce, a customer often goes through several steps to complete a transaction. These steps are tightly linked, and each step may need results from the previous one. It is preferable that all related interactions are handled by the same server rather than being distributed by a load balancer.

Compatibility issues with certain frameworks: Some frameworks perform special operations on the session. When the session is shared to a cache server, these operations can break, making the cost of fixing the issue high. In such cases, it is better to route all actions of a user to the same server.

Session persistence (also called sticky sessions) is a mechanism on load balancers that identifies the relationship between a client and a series of requests, ensuring that related requests are directed to the same backend server.

For example, Nginx provides a session persistence mechanism via the ip_hash directive in the upstream module. This directive routes all requests from a specific IP address to the same backend server, establishing a stable session.

upstream backend {
    ip_hash;
    server 192.168.1.106:80;
    server 192.168.1.107:80;
}