Note-
Recommended to read PART-5.
Introduction
We all know that when we login into Netflix for the first time, it remembers our preferences, last watched content and our profile details etc., so next time when you open Netflix, you don’t have to login again. How does it happen? When you open Netflix, how does the web server know all these details?
That’s because server stores the session details of the user as well. Where? Let’s see.
Stateless vs Stateful Architecture
When the web server does not remember the session details (state) of the user like — IP address, Device Id, cookies, authentication, tokens, last activities, days after last login, etc, then it’s called Stateless Architecture. As a result, every time a user logs in, the request can go to any web server and every web server will respond with the same response (loading the home page of the requested website).
If we decide to make our architecture stateful where we will store the state of the user, we need to ensure that the web server that returns the response must remember the state and instead of sending back the home page, it should send the last session. There is a catch though !
When a user requests for a website, the request reaches the load balancer and since we have horizontal scaling of the web servers (multiple servers), the request reaches to one of the web servers. The problem is what if the request reaches a web server that does not store the state of that user, it will not be able to load the state, rather it will ask for the login once again. (See below)
So if web server A stores the session of user A, every time a request arises from user A it should only reach to web server A for our stateful architecture to work.
Therefore, every web server should remember the state of every user (request).
One way to achieve the above is to ensure web servers share the session data amongst each other in a synchronous manner. However, there can be data inconsistency and also it would be highly inefficient.
Extracting out the data
The better way would be to NOT store the state of the user in the web server and store it out in a common pool where each server can read from it and use it. Now since state data is not a primary data which needs to stored in form of relational table, it can mostly be stored in the form of document (json or xml), we can store it in a NoSQL Database (like DynamoDB). This also ensure minimal latency to fetch the state of the user.
Now, that we have implemented the stateful architecture, let’s see how our design from PART-5 looks like —
Till now, we have seen so many components. In the next one, we will talk about another very important component, message queues. See you in part-7.