Sticky Sessions

Cookie-based affinity, source IP hashing, JSESSIONID pinning, and how sticky sessions conflict with horizontal scaling.

Overview

Overview Sticky sessions (also called session affinity) ensure that a client's requests are consistently routed to the same backend server. This is necessary when server-side session state is stored in-process (in memory) rather than in a shared external store. If a subsequent request lands on a different server, that server has no knowledge of the session and the user experiences an authentication failure or lost cart.

Cookie-based affinity is the most common implementation. The load balancer inserts a cookie (e.g., AWSALB on AWS ALB) into the first response. On subsequent requests, the load balancer reads this cookie and routes to the pinned backend.

Source IP hashing is an alternative that requires no cookie insertion. The client IP is hashed to select a backend. This is weaker: clients behind NAT share one IP and all land on the same backend. IP changes (mobile roaming, VPN) break the affinity.

The fundamental problem with sticky sessions is that they undermine horizontal scaling. If a pinned backend is removed (deployment, failure, scale-in), all its pinned clients lose their session. Sticky sessions also complicate blue-green and canary deployments.

The correct long-term solution is to externalize session state to a shared store (Redis, DynamoDB) so any backend can serve any request. Sticky sessions should be treated as a temporary workaround, not an architecture goal.

Key concepts

Cookie-Based Affinity
The load balancer inserts a cookie (e.g., AWSALB) into the first HTTP response identifying the backend. All subsequent requests carrying the cookie are routed to the same backend. The most reliable form of stickiness.
Source IP Hashing
The client IP address is hashed to select a backend. No cookie required but fragile: NAT concentrates many clients on one backend; IP changes break affinity.
JSESSIONID Pinning
Some load balancers read the JSESSIONID cookie set by the Java application server and use it as the affinity key, avoiding the need to insert a separate load-balancer cookie.
Externalized Session State
Session data stored in a shared external store (Redis, DynamoDB). Any backend can serve any request because session state is not local. Enables true stateless horizontal scaling.

When to use it

  • Migrating a legacy stateful Java EE or PHP application to a load-balanced deployment without refactoring session handling
  • Understanding why ALB stickiness must be disabled before autoscaling works correctly
  • Designing a session migration strategy for a monolith decomposition project
  • Explaining to a team why an autoscaling event caused user logouts

Interview questions

  • How do you enable sticky sessions on an AWS ALB, and what are the tradeoffs?
  • A team complains users are being logged out during deployments. What causes this and how do you fix it?

Sign up free to read the full topic

More Networking topics

Start free on Cariara · Coding problems · System design studio