System Design Architecture: Stateful vs. Stateless
When designing a system that is supposed to be easily scalable, you first try to scale the different components of the system.
On the client layer, you have your client device which could be a desktop or a mobile device
On the application layer, you will have your CDNs, Load Balancers, App Servers or Web Servers, and other User management utilities.
On the database layer, you will have your source and replicated databases.
When it comes to user sessions where are you going to store these sessions?
You can’t store them in the application layer, because app servers will have cached memory storage that will update the user session.
This introduces the need for persistent storage of the user session. The best place to store the user sessions would be inside the database layer. How you store this depends on the type of architecture that you are trying to choose.
There are two types of architecture for storing the user session state.
Stateful architecture:
Authentication session that requires users to log in to their accounts requires maintaining session states. Other multi-action processes also require maintaining sessions. In a stateful architecture, the server stores the client state from one request to the next request.
When the user goes to a different device such as a cell phone or desktop that they have never logged in before, then initially they would initially require an authentication process, like 2FA before having the user session state from that device being stored onto the server. So the session state actually is being stored on the server.
The following image shows how a stateful architecture is designed.
Stateful architecture stores and maintains the user session on a single server. An HTTP request coming from this user cannot be routed to another server because the response would fail.
Therefore all the requests coming from a user must be routed to its designated server to access the state of that user. This makes it very difficult for the architecture to scale because adding or removing servers would cause many failure point issues from the requests received from the users.
To ensure the feasibility of this architecture we could use sticky sessions in load balancers. However, this would add a lot of overhead.
Stateless architecture
A stateless service as a whole usually still needs to handle state in some form. Stateless simply refers to the fact that this state isn’t tracked in server-side sessions [0].
In a stateless architecture, HTTP requests coming from users can be sent to any webservers because the user session is not stored on the application layer but on shared storage space on the database layer.
Historically client devices were very limited in hardware and software power to process the additional complexities of maintaining sessions. Therefore most of the heavy lifting was done on the server side.
However, due to technological advances and diverse growth in infrastructure and computing power, personal and professional computing devices that don’t act as servers are powerful enough to handle session states.
The beauty of this architecture is that when we move the idea of storing the user session data from the application layer onto the persistent data storing layer, it allows the system to be more simpler and scalable.
The added flexibility of autoscaling the web servers on the application layer depending on the network traffic allows you to not worry about overhead.
Thank you for reading 🙂
One clap 👏🏽 for next curated system design article
Sources:
[0] . Virtasant. “Stateful vs Stateless Architecture: Why Stateless Won.” Virtasant, 27 Jan. 2022, www.virtasant.com/blog/stateful-vs-stateless-architecture-why-stateless-won
[1]. Xu, Alex. System Design Interview — An Insider’s Guide. Independently published, 2020.
