Keeping a client on one backend
Sometimes a backend holds state for a client, such as an in memory session or a warm cache. Sticky sessions, also called session affinity, make the load balancer keep sending the same client to the same backend.
The simplest stickiness maps a cookie or client address to a chosen backend. But naive mapping breaks badly when the backend pool changes.
Why consistent hashing helps
A plain hash of the client modulo the number of backends remaps almost every client when one backend is added or removed. Consistent hashing places backends and clients on a ring, so adding or removing a backend only moves the clients near that backend, leaving the rest stable.
- Stability: most clients keep their backend during scaling.
- Even spread: virtual nodes smooth out the ring so load stays balanced.
The tradeoff
Stickiness improves cache hit rates and session continuity, but it weakens balance: a hot client stays pinned to one backend. It also makes that backend a single point of failure for its clients, so designs keep critical state in a shared store rather than relying on stickiness alone.
Key idea
Sticky sessions pin a client to one backend, and consistent hashing makes that mapping survive pool changes by moving only nearby clients.