Sticky Session
A load balancer feature that routes all requests from the same client to the same backend server. Needed when servers store session state locally.
What is Sticky Session?
In short
A sticky session is a load balancer setting that pins every request from one client to the same backend server for the life of that client's session, instead of spreading requests across the pool. It exists so that servers which keep session data in their own local memory can keep finding that data, since the client always lands on the machine that holds it.
What a sticky session actually is
When you put several application servers behind a load balancer, the default behavior is to spread incoming requests across all of them. Request one might go to server A, request two to server B, and so on. That works perfectly as long as the servers are stateless, meaning any server can handle any request because all the important data lives somewhere shared like a database or a cache.
The problem starts when a server stores something in its own local memory that the next request needs. The classic example is a login session. You sign in, server A creates a session object in its RAM and hands you a session ID. On your next click the load balancer sends you to server B, which has never heard of your session ID, so it thinks you are logged out.
A sticky session fixes this by telling the load balancer: once a client has been sent to server A, keep sending that client to server A. This is also called session affinity or session persistence. The stickiness lasts for the duration of the session, then resets.
How the load balancer makes it stick
There are two common mechanisms. The first is cookie based affinity. The load balancer injects its own cookie into the response, for example AWSALB on an AWS Application Load Balancer or a route cookie on HAProxy. On every later request the client sends that cookie back, the load balancer reads it, and routes to the server named inside it. This survives even if the client's IP changes.
The second is IP based affinity, sometimes called source IP hashing. The load balancer hashes the client's IP address and uses the result to always pick the same backend. Nginx does this with the ip_hash directive. It needs no cookies, so it works for non browser clients, but it breaks down when many users share one IP behind a corporate NAT or mobile carrier, because they all hash to the same server.
Either way the affinity has a timeout. AWS ALB lets you set the stickiness duration from one second up to seven days. When it expires, the next request is load balanced normally and a fresh affinity is established.
When to use it and what it costs
Sticky sessions are the quick fix when you have a legacy app that already stores session state in local memory and you cannot easily change it. They are also useful for stateful protocols like WebSocket connections, where a long lived connection should stay on one server, and for in process caches where re routing would mean a cold cache miss every time.
The big cost is that they fight against the whole point of horizontal scaling. Load gets uneven, because a handful of heavy users can pin themselves to one server while others sit idle. Worse, if that server crashes, every session living only in its memory is lost, so those users get logged out. Auto scaling also suffers, since new servers you add stay empty until brand new clients arrive.
The cleaner long term answer is to make servers stateless and move session data into a shared store such as Redis, Memcached, or a database. Then any server can serve any request and you can drop stickiness entirely. Sticky sessions are best treated as a bridge, not a destination.
A concrete example
Picture a Java shopping site running on three Tomcat servers behind an AWS Application Load Balancer. A shopper adds items to a cart that Tomcat keeps in its HttpSession, which lives in that one server's heap.
Without stickiness, the shopper adds a laptop on server A, then clicks checkout and gets routed to server B, whose session has an empty cart. The order looks wrong and the shopper leaves.
Turn on ALB stickiness with a one hour duration. Now the ALB sets the AWSALB cookie on the first response, and every later request carries it back, so the shopper stays on server A and the cart stays intact through checkout. The trade off the team accepts is that if server A dies mid session, that shopper's cart is gone. That risk is exactly why most teams eventually move the cart into Redis and switch the servers to stateless.
Where it is used in production
AWS Elastic Load Balancing
Application and Classic Load Balancers support cookie based stickiness with a configurable duration up to seven days using the AWSALB cookie.
Nginx
Offers IP hash affinity via the ip_hash directive, and cookie based affinity through the sticky cookie directive in Nginx Plus.
HAProxy
Implements persistence with stick tables and an inserted route cookie, pinning a client to one backend until the entry expires.
Kubernetes
Services support sessionAffinity set to ClientIP, which hashes the source IP so a client keeps reaching the same pod.
Frequently asked questions
- What is the difference between a sticky session and a normal load balanced session?
- A normal load balanced session can land on any server on each request, so it only works when servers are stateless. A sticky session pins one client to one server for the whole session, so it is needed when that server holds session data in its own local memory.
- Do sticky sessions break horizontal scaling?
- They partly do. Load becomes uneven because some servers get pinned to heavy users while others stay idle, and newly added servers stay empty until fresh clients arrive. They also create a single point of failure since losing one server logs out everyone pinned to it.
- Cookie based or IP based stickiness, which should I use?
- Use cookie based affinity for web browsers, because it survives IP changes and is accurate per client. Use IP based affinity only when you cannot set cookies, and be aware it sends every user behind a shared corporate or mobile NAT to the same server.
- How do I avoid needing sticky sessions at all?
- Make your servers stateless by moving session data out of local memory into a shared store like Redis or Memcached, or into a signed cookie or JWT held by the client. Then any server can handle any request and you can turn affinity off.
- What happens when the server holding my sticky session crashes?
- Any session state that lived only in that server's memory is lost. The load balancer reroutes you to a healthy server, but that server has no record of your session, so you typically get logged out or lose in progress state like a shopping cart.
Learn Sticky Session hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on Sticky Session as part of a larger topic.
Monotonic Reads
Once you have seen a value, you never see an older one, the minimum useful consistency guarantee
advanced · consistency models
Sticky Sessions
Pinning users to the same server, when stateless just isn't possible
foundation · load balancing proxies
Read-Your-Writes
You always see your own updates immediately, the consistency users expect but rarely get by default
advanced · consistency models
Session Affinity
The broader concept behind sticky sessions, soft preferences vs. Hard pinning
foundation · load balancing proxies
Distributed Session Management
Managing user sessions across multiple servers, sticky sessions, centralized stores, and token-based approaches
intermediate · security architecture
See also
Related glossary terms you might want to look up next.
Load Balancer
Distributes incoming traffic across multiple servers so no single server gets overwhelmed. Like a traffic cop directing cars to different lanes.
Session
A way to maintain state across multiple HTTP requests. The server stores data about a user and gives them a session ID (usually in a cookie).
Stateful
A system that remembers previous interactions. The server keeps track of client state between requests, making it harder to scale but sometimes necessary.
DNS
The phonebook of the internet. Translates human-readable domain names (google.com) into IP addresses that computers understand.
Proxy
An intermediary server that sits between the client and the destination server. Forward proxies act on behalf of clients; reverse proxies act on behalf of servers.
Reverse Proxy
A server that sits in front of your backend servers and forwards client requests to them. Handles SSL termination, caching, and load balancing.