Should You Use Sticky Sessions?

A discussion.

Before trying to answer this question, let’s understand the role of sticky sessions.

Sticky sessions make sure that all of a user's requests are consistently directed to the same server instance for the duration of their session.

Here’s what it looks like:

You can play around with the diagram on Eraser.io

But why is this important?

It’s important when the server instance physically stores some user-specific information without which the user’s experience gets impacted.

Here are a few examples:

• Session Objects: When a user establishes a connection with the server, the server may create a session object specific to that client-server pair. This object is stored in the server’s memory and contains information about the session.

• Shopping Cart Details: In an e-commerce application, a user’s shopping cart details may be stored on a specific server instance.

• File Processing: Consider a scenario where a user initiates a file processing task on a server. The server instance handling the task may need to maintain the state of the processing and provide updates to the user.

In all of these examples, only with sticky sessions, subsequent requests from the same user are directed to the same server instance so that the server can access and maintain the session object.

There are a few advantages to this approach:

• The user-specific data stored on a server remains consistent throughout the user’s session.

• You get better performance by directing a user’s requests to the same server instance.

• There’s also a cost advantage with sticky sessions where you don’t have to invest in external storage for session information.

Downsides of Sticky Sessions

Despite their advantages, however, sticky sessions have a couple of downsides:

• Sticky sessions will stick. Hence the name. They defeat the purpose of a load balancer because multiple users might get stuck to one instance while other instances sit idle and don’t receive any requests. Ultimately, this will create scalability challenges.

• The session is gone if the server goes down. Since the session is usually stored in memory, it’s tied to the life of the server instance. Of course, the user is redirected to another instance but the session information is gone. In practical terms, this might mean that the user needs to log in once more or stuff their shopping cart from scratch again. Not a great user experience, in my view.

Where Are Sticky Sessions Useful?

Sticky sessions can be useful in a couple of scenarios:

• WebSockets rely on persistent sticky connections.

• A basic implementation of the file-processing example where a user needs to check the status of a file being processed. Even there, for more advanced scenarios, you might want to store the status information for file processing in a separate store.

Alternative to Sticky Sessions

In my view, instead of relying on sticky sessions, it's often better to store session information in a distributed session store.

A distributed session store is a separate, centralized storage system that holds session data. Popular options for distributed session stores include Redis and DynamoDB.

The diagram below shows this setup:

You can play around with the diagram on Eraser.io

Here’s how it works:

• When a user’s request arrives at the load balancer, it can distribute the traffic evenly across the available server instances. No need for sticky sessions.

• The server instance that receives the request retrieves the relevant session information from the distributed session store.

• After processing the request, the server instance updates the session information in the distributed store. This ensures that the latest session data is persisted.

• Subsequent requests from the same user can be routed to any available server instance, as the latest session information can be retrieved from the distributed store.

Advantages of A Distributed Session Store

The key advantages of using a distributed session store are as follows:

• Fault Tolerance: If a particular server instance goes down, the session information is not lost.

• Scalability: As the system scales and more server instances are added, the load balancer can distribute traffic evenly without being constrained by sticky sessions. This is good for resource utilization and performance. Also, it helps make your application layer stateless.

• Flexibility: With session information in a distributed store, you have more flexibility in terms of server maintenance and updates. Server instances can be taken offline for maintenance without disrupting the user experience.

So - what do you think about the use of sticky sessions? Do you still prefer using them?

---

Shoutout

Here are some interesting articles I’ve read recently:

• How to build good relationships inside and outside your engineering team by

  Gregor Ojstersek

• “Don’t Talk to Strangers” also applies to Software Development by

  Raul Junco

• State Management & Data Fetching Libraries in React by

  Petar Ivanov

---

That’s it for today! ☀️

Enjoyed this issue of the newsletter?

Share with your friends and colleagues.

See you later with another edition — Saurabh