Two ways to keep session state
When sessions live in server memory, the balancer must somehow find the server that holds a user's data.
- Sticky sessions pin a user to the same server for the whole session.
- Shared store keeps session data in an external cache so any server can read it.
How they differ
With stickiness the balancer routes by a cookie or hash. With a shared store every server is interchangeable.
Tradeoffs
- Sticky sessions are simple but break when a server dies, losing its sessions.
- They also unbalance load, since busy users stay glued to one node.
- A shared store survives node failures and balances evenly, at the cost of an extra dependency.
Practical notes
- Prefer a shared store for resilience in large deployments.
- If you use stickiness, keep sessions short and tolerate occasional loss.
- The shared store itself must be replicated so it is not a new single point of failure.
Key idea
Sticky sessions are easy but fragile, while a shared store makes every server interchangeable and resilient to node loss.