Stateless vs. Stateful Load Balancing

Stateless and stateful load balancing represent two distinct methods for distributing traffic among multiple servers or resources.

Stateless Load Balancing

A stateless load balancer keeps no record of which server each client used before. It makes each routing decision based only on the incoming request data, such as the URL or the headers, together with the current load on each server. Because it has nothing to remember, it can send each request to whichever server is best placed to take it, and the load spreads evenly.

Example: Consider a product search page. Any server can answer any search, because the request itself carries everything needed to answer it. A stateless load balancer can send each search to whichever server is least busy.

Stateful Load Balancing

In contrast, a stateful load balancer keeps each client on the same server. This is also called sticky sessions. The load balancer does not store the session data itself. It only makes sure that each client's requests reach the server that holds that client's session data. This is useful when requests belong to an ongoing session and the data for that session lives on one server.

Example: Suppose a web application that requires users to log in to access their personal information. A stateful load balancer routes requests from the same user to the same server, so the session data held on that server, such as the user's login session, stays available. This holds only while that server stays up and the server pool does not change.

There are two common ways to keep a client on the same server:

• Source IP Affinity: The load balancer picks a server from the client's IP address, usually by hashing it, so the same address keeps reaching the same server. No stored table is needed, because the hash always gives the same answer. This breaks when the client's IP address changes, as often happens on mobile networks. It can also overload one server, because many users behind one office or carrier gateway share a single address.

• Session Affinity: The load balancer picks a server from a session identifier, such as a cookie or a URL parameter. Often the load balancer sets this cookie itself, naming the chosen server. The client then keeps reaching that server even when its IP address changes. The term "session affinity" is also used more loosely, as another name for sticky sessions in general.

Both methods stop working when the chosen server fails. The client is then sent to a different server, which does not have its session data.

Do You Need Sticky Sessions at All?

Session data does not have to live on the app server. You can keep it in a shared store, such as Redis, that every app server can reach. The app servers then hold no session state of their own, which makes them stateless.

This is usually the better default, for three reasons:

• Any server can handle any request. The load balancer can spread traffic evenly, with no need to remember which user belongs to which server.
• A server can fail without logging anyone out. The sessions live in the shared store, not on the server that failed.
• Scaling is simple. Adding or removing servers does not move users or lose their sessions.

The shared store has its own costs. Every request now depends on it, so it must be highly available. Each request also makes one extra network call, which usually adds about a millisecond inside one data center.

Sticky sessions still make sense in a few cases:

• The state is the connection itself. A WebSocket connection or a live game session exists on one server, and it cannot be moved into a shared store.
• The per-user state is too large to fetch on every request. Examples are an in-memory cache built for one user, or a partly uploaded file on local disk.
• An existing application keeps sessions in memory, and changing it would cost more than it saves.

Sticky sessions have costs too. Load can become uneven, because a few busy users can keep one server busy while others sit idle. New servers added during a traffic spike receive only new users, so they relieve the busy servers slowly. And when a server fails, every session it held is lost.

The choice depends on where the state lives. When session data can sit in a shared store, keep the app servers stateless and use a stateless load balancer. Use stateful load balancing when the state has to stay on one particular server.