Stateful VS Stateless architecture
Stateful VS Stateless architecture

Alright so you type a URL of a website and then authenticate yourself to the server that you are who you say you are, usually with a username and a password and then you view your profile. Right? simple isn’t it? It’s the most simplest form. That’s what a user sees but underneath there is a lot more going on, which brings us today to discuss stateful and stateless applications. Let’s begin with an example.

Stateful applications

Consider an application which has two pages or services “Login” and “ViewProfile”, and the user Bob sends a request to the server1 to the login page which looks like this http://server1/login?username=bob&password=bob123 now the server queries the database to validate these credentials and if they are, the server responds with a Status: 200 OK response and sets a session variable or a global variable in the server.

Now when the user Bob requests for the ViewProfile page the server remembers the session variable and responds with a 200 OK response. Usually there is an array or some sort of session variable that tells that this user is logged in.

Advantages of Stateful applications

The next time Bob makes a call to ViewProfile page the server won’t have to query the database thus storing the state and saving the trouble of querying the database twice. And maybe it will be faster at the backend.

Disadvantages of Stateful applications

So where does it go wrong?

Remember the session variable is stored in the memory, the RAM. So if i literally do have multiple servers and now if the user Bob tries to request the ViewProfile page to server2 it will fail. Why? because server2 does not have the session variable stored because Bob logged into server1.

This means we can not scale our network horizontally, and Bob has to authenticate again every time he connects to a different server.

Now you might say “I don’t go to server1 or server2”, what really happens is that there is another machine called a Load Balancer, what it does is simply balances the load/traffic.

Bob does not know about server1 or server2, he knows about LB. So he makes a login call to LB, and LB randomly assigns a server and let’s say it picks up server1 and we do the login call, the server queries the database and we get a 200 OK response. Now Bob calls for the ViewProfile page, if he gets lucky he might get server1 but what if the LB picks up server2? The call will fail because he is not logged into server2. Imagine logging into facebook.com and then you go to profile, and you have to login again.

Stateless applications

Now consider the same application with our two services “login” and “ViewProfile” with multiple servers and a Load Balancer and a database. Alice makes a call to the login page and authenticates herself using her credentials, everything is same as before, but now when the database authenticates those credentials it also sends a token (usually a pseudo-random token) to the user (in our case Alice), now with each request Alice makes, the token is send along with the request.

Now Alice request for ViewProfile page, if the LB decides to take her to server1, the server1 queries the database and validates that token and if the token that Alice has is same as the one sent by the database we get an 200 OK response. On the other hand if the LB decides to take her to server2 that’s fine too. the server2 will again query the database and validate the token. It does not have to be the same database, it could be another intermediate database.

Advantages of stateless applications

Unlike the stateful application we can scale out network horizontally, usually used in larger companies.

Disadvantages of stateless applications

As stated before “with each request the user makes the token is attached with it”, so it has an extra cost of querying to the database for each request. but this type of authentication is more soft.
['Rudra Sonkusare']
['Web Development', 'Information Technology', 'Information Security', 'Infosec', 'Cybersecurity']