We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningFoundation · Load Balancing & Proxies
A load balancer feature that routes all requests from the same client to the same backend server. Needed when servers store session state locally.
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.
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.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Sticky Session across a run of lessons, not one page. These 4 alone are about 75 minutes of step-by-step reading, every one with a quiz.
Pinning users to the same server, when stateless just isn't possible.
Once you have seen a value, you never see an older one, the minimum useful consistency guarantee.
You always see your own updates immediately, the consistency users expect but rarely get by default.
Managing user sessions across multiple servers, sticky sessions, centralized stores, and token-based approaches.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Sticky Sessionspay once,
yours for life
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Monotonic Reads
Once you have seen a value, you never see an older one, the minimum useful consistency guarantee
Read-Your-Writes
You always see your own updates immediately, the consistency users expect but rarely get by default
Distributed Session Management
Managing user sessions across multiple servers, sticky sessions, centralized stores, and token-based approaches
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 in front of your web servers that receives every request first, passes it to one of them and returns the answer. It handles TLS, load balancing, caching and routing, and hides the servers behind it.
This page explains the idea. The "Sticky Sessions" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Sticky Sessions lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Sticky Session in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
