What is a sticky session in load balancing?

In scenarios where load balancing is used to distribute client requests across multiple backend servers, a challenge arises when requests from the same client are directed to different servers. This can cause issues, particularly if the session data crucial to the user’s interaction is stored locally on one server. To address this, sticky sessions (also known as session affinity) are used. This technique ensures that all requests from a specific client are directed to the same backend server throughout their session, enhancing the continuity and reliability of user interactions. Sticky sessions are vital for web applications where session data is saved locally on the server that initially handled the user’s request. Now, let us delve into sticky sessions, examining their advantages and disadvantages and discussing their implementation on cloud platforms such as AWS, GCP, and Azure.

How sticky sessions work

Initial request
- When a user first interacts with the web application, the load balancer sends this request to any of the backend servers based on the selected load balancing algorithm (Round-robin, Least connection, etc.). Subsequent requests may be directed to the same server based on session information, such as cookies, to ensure continuity.
Session affinity mechanism

Here are two common mechanisms used to implement session affinity:

Cookies: The load balancer has another duty of placing a particular cookie that resides on the user’s browser to recognize which server at the backend is handling the session. This cookie relates to a specific server and holds information connected to the session.
IP address: The load balancer can use the client’s IP address for session tracking; it ensures that all requests from the same client’s IP are forwarded to the same backend server. However, this method has been deemed ineffective due to factors, some of which include shared proxies and NAT, where many users are seen as one IP address and dynamic IP addresses that tend to change, hence interrupting the session. These are some of the reasons that make IP-based affinity less reliable than cookie-based affinity.

Subsequent requests
- In case of subsequent requests from the same user, the load balancer reads the session affinity information in cookies or by IP address to relay the requests to the same backend server. This means that the session data of the user will be readily available and consistent throughout the session.

Here is a demonstration of how requests are routed in sticky sessions vs. non-sticky sessions:

Examples

Let’s take a look at some examples where we need to use sticky sessions:

E-commerce website: In an e-commerce website, when a user adds products to their shopping cart, this cart information is stored on the server associated with their session. Sticky sessions are crucial here because, without them, a user’s activities could be handled by different servers, potentially causing the loss of cart information. For example, if a user adds items to their cart and is routed to a different server, their cart might appear empty. This inconsistency could discourage the user from completing their purchase.
Web application with user login: When a user logs into a web application, their session information, including login status and other pertinent details, is stored on the server. Sticky sessions ensure that the user remains connected to the same server, enhancing consistency. Without sticky sessions, users might be redirected to another server and prompted to log in again, as the session information does not transfer with them. This can lead to frustration and dissatisfaction, negatively impacting the user’s experience with the service.

Benefits and drawbacks

Here are the benefits and drawbacks of the sticky session:

Benefits	Drawbacks
Consistency: It ensures that data stored locally on a server for quicker access remains available in the server’s cache throughout the session. This helps maintain a seamless user experience by providing continuous access to session-specific data.	Load imbalance: It may result in an unfair distribution of loads since some of the servers may end up handling more sessions than others.
User experience: It avoids instances of inconveniences that may arise if a given session is run on a different server from the session data.	Scalability: It makes horizontal scaling even more difficult since the state is tied to certain servers.
Performance: It improves the overall application performance since it reduces frequent access to session information from a central place or a database.	Failover complexity: It means that when a server dies, the sessions which were bound to this server can be destroyed if mechanisms like session replication are not used.
Simplicity: This approach enhances session management by keeping session data on the server. It simplifies the architecture by centralizing data management and reducing the complexity of handling session data across multiple servers.	Resource utilization: It increases general resource consumption on specific servers because the data for each session must be kept on the corresponding server.
Reduced latency: It reduces the latency by storing session data on the server which is actually processing the session data, avoiding other network hops.	Redundancy: It needs extra features to back up session data on other servers so that the system is more reliable and secure, even if one server fails to function.

Sticky sessions in major cloud platforms

Here is an overview of how sticky sessions are handled in major cloud platforms:

AWS (Amazon Web Services)

It provides the Amazon Elastic Load Balancer, which distributes traffic to numerous instances for optimum utilization. It enables sticky sessions using the Application Load Balancer (ALB) and the Classic Load Balancer (CLB).

ALB employs an application layer cookie solely for sticky sessions; it guarantees the association of all the users’ requests with the same server in a single session. CLB supports sticky sessions to make use of cookies created by the load balancing node or cookies managed by the application. Both of them provide session affinity and enhance the user experience by channeling the request to the same backend server.

GCP (Google Cloud Platform)

Load balancing in Google Cloud Platform is enabled with session affinity in the HTTP(S) Load Balancer. This can be done by using the client IP or the HTTP cookies so that a given user will always be routed to the same backend server.

Azure (Microsoft Azure)

Microsoft Azure can use session affinity offered by the Application Gateway. This feature employs cookies to keep user’s sessions consistent so that all their requests will be directed to the single backend server.

Conclusion

Sticky sessions can be described as a property of load balancing that ensures that a user’s session is always run by the same backend server. This technique is helpful for programs in which session data is stored at the local level and has to be easily retrievable. Thus, although sticky sessions provide substantial advantages regarding session persistency and users’ satisfaction, they also raise issues connected with load balancing and the system’s scalability.

Quiz

Free Resources