Session Persistence
Session persistence means that all requests from a user during a visit always land on the same server. This is necessary when that server holds information about the user in its own memory that other servers don't know about.
Large websites don’t run on a single computer. Behind the address are often dozens of similar machines sharing the work. A distributor in front sends each request to one of these machines. Session persistence means: a user stays with the same machine throughout their visit. A session is everything that happens between opening and leaving a page. Without this binding, every click could land on a different machine that doesn’t recognize the user.
Why the shopping cart is otherwise empty
The classic example is an online shop. You put headphones in the cart, and the server remembers this in its own memory. On the next click, you land on a different server of the same site. This server has never heard of your headphones, and the cart appears empty. This is exactly what session persistence prevents.
The same problem applies to logins. If a server internally notes that you’re logged in, the neighboring server doesn’t know about this note. You would seemingly randomly keep getting logged out. Such errors are particularly annoying because they occur irregularly and are hard to track down.
For AI applications, the issue becomes important for a different reason. A chatbot needs to know the previous conversation history, otherwise it responds nonsensically. Many systems keep this history and expensive intermediate results on a particular machine. If the next question lands elsewhere, everything has to be recalculated. This costs computing time and therefore money.
Cookies, IP addresses, and the distributor
Responsible for this is the distributor in front of the servers, called the load balancer. It must remember which user belongs to which server. The most common technique for this is a cookie: a small text note that the distributor places in the user’s browser. It contains an identifier for the assigned server. With every further request, the browser sends the note along, and the distributor knows where to route it.
A simpler variant uses the IP address, i.e. the number under which a device can be reached on the internet. From this number, the distributor always calculates the same target server. This works without a cookie, but is less reliable. In corporate networks and mobile networks, many people share one IP address, so everyone ends up on the same server.
There is also the opposite approach: forgo the binding and place the session data in a shared, fast database. Every server can read it there. Such servers are called stateless. The advantage is robustness, since nothing is lost if a server fails. The disadvantage is additional latency and another system that can fail.
Visible during outages and load spikes
As a user, you mainly notice session persistence when it’s missing. The shopping cart empties, a half-filled-out form suddenly disappears, or a login doesn’t hold. Such effects often occur after updates, when servers are swapped out. The binding can also break under very high load.
In tech news, the term mostly appears in connection with cloud services. Providers like Amazon or Google sell load balancers where sticky sessions are a configurable option. Sticky session is simply another word for the same principle.
Experts tend to view the binding critically. It distributes load unevenly, because popular users can’t be moved. If a server fails, all users bound to it lose their session. That’s why the common practice today is: offload session data, and only use binding where it can’t be avoided.