Sticky Sessions (Session Affinity)

Sticky sessions are a confession that your application has a memory problem—it remembers things it shouldn't, in places it shouldn't remember them.

When a server stores session state (your login status, your shopping cart, the form you're halfway through), you must keep talking to that same server. But load balancers exist specifically to distribute requests across many servers. Sticky sessions are the compromise: the load balancer promises to send you back to the server that remembers you.

This works. It also creates problems that wouldn't exist if the application were designed differently.

The Problem: Server-Side State

Imagine you're shopping online. You add items to your cart (stored on Server A), browse a few more pages (still Server A), then your phone switches from WiFi to cellular. Your IP address changes. The load balancer sends your next request to Server B.

Server B has never seen you before. Your cart is empty. You're logged out.

This happens because the application stores state on individual servers rather than somewhere all servers can access. Sticky sessions prevent this by ensuring that once you're assigned to Server A, you stay on Server A.

How Load Balancers Maintain Stickiness

Cookie-based persistence is most reliable for HTTP traffic. When you first connect, the load balancer adds a cookie to the response—something like SERVERID=backend-a. Every subsequent request includes this cookie, and the load balancer routes you accordingly.

This survives IP changes, works through proxies, and handles server failures gracefully (the load balancer can reassign you and update the cookie). The trade-off: it only works for HTTP, and clients must accept cookies.

IP-based persistence hashes your IP address to consistently select the same server. It works for any protocol and requires no client cooperation. But it breaks when IPs change, and it distributes poorly when many clients share an IP through corporate NAT—suddenly one server handles an entire company.

SSL session ID uses the TLS handshake identifier. Less common, but useful when you need stickiness for encrypted traffic without inspecting it.

The Trade-offs Nobody Hides

Sticky sessions limit everything load balancers are supposed to do well:

Load distribution becomes uneven. If one user generates ten times the traffic of others, their server bears that load while others sit idle. The load balancer can't help—it promised to send that user to that server.

Scaling down becomes complicated. You can't just remove a server; users have sessions there. You either wait for sessions to expire (connection draining) or accept that some users lose their state.

Failover becomes painful. When a server with sticky sessions fails, those sessions are gone. The users don't gracefully move to healthy servers—they start over. Lost carts. Lost forms. Lost authentication.

This is the fundamental tension: sticky sessions solve the symptom (users losing state) while preserving the disease (state stored in the wrong place).

Connection Draining: The Graceful Exit

When you need to remove a server for maintenance, connection draining lets existing sessions finish while blocking new ones:

1. Mark the server as "draining"
2. Stop sending new sessions there
3. Allow existing sticky sessions to continue
4. Wait for sessions to expire or complete
5. Remove the server

This can take hours if session timeouts are long. It's civilized, but it's not fast.

Better Architectures

Sticky sessions exist because applications store state on individual servers. The cleaner solution is to store state somewhere all servers can access:

Externalized session storage puts sessions in Redis, a database, or a distributed cache. Any server can serve any request because any server can read any session. Server failures don't lose sessions.

Client-side sessions store all state in signed, encrypted cookies sent with each request. The server doesn't remember anything—it reads everything it needs from the request itself.

Stateless authentication with tokens like JWT embeds all authentication information in the token. No server-side session storage means no stickiness required.

These approaches align with how modern cloud infrastructure works: servers are ephemeral, scaling is dynamic, and any server should be able to handle any request.

When Sticky Sessions Make Sense

Legacy applications that store session state in memory and can't be easily refactored. Sticky sessions let them work behind load balancers without modification.

WebSocket connections are inherently stateful—the connection itself is the state. Stickiness ensures the connection stays with the server that holds its other end.

Short-term solutions while migrating to stateless architecture. Sometimes you need load balancing today and can fix the architecture next quarter.

Heavy session state that's expensive to serialize. If sessions contain large data structures, externalizing them might add unacceptable latency.

When to Avoid Them

New applications should be designed stateless from the start. The architectural patterns are well-understood and the tooling is mature.

Cloud-native applications where instances scale dynamically. Sticky sessions fight against auto-scaling—you can't easily add or remove capacity.

High-availability requirements where server failures shouldn't affect users. Sticky sessions mean server failures do affect users.

Monitoring What Matters

If you're using sticky sessions, watch for:

• Session distribution across servers—uneven distribution means stickiness is preventing good load balancing
• Session count per server—identifies servers carrying disproportionate load
• Draining duration—how long servers take to shed sessions during graceful shutdown
• Sessions lost on failure—the real cost when servers go down