One day Minnie met Mickey at a Fruits shop. Mickey looked lost. Minnie tried to find out.
Minnie – Hey Mickey! How are you? What are you thinking?
Mickey – err…Hey Minnie, Nice to see you.
Minnie – You look lost. What’s up?
Mickey – You remember that day you explained to me about the difference between Authentication and Authorisation in a Story
Minnie – Yes I do, did you explain that in the class. Any issues there?
Mickey – No, it was awesome. If fact everyone in the class liked it a lot
Minnie – Then?
Mickey – My teacher asked me to tell a story about Stateful and Stateless services in the next class and I am trying to figure that out since yesterday.
Minnie – Oh-kay! Got it. You understand better with a story.
Mickey – Yeah, so here we go….
Minnie – Do you remember last week your TV broke and you called the call center to check if your TV is covered under the replacement warranty.
Mickey – Yes I do.
Minnie – So when you called what happened next
Mickey – Well! the customer care representative asked me a series of questions to authenticate myself and then he discussed my issue.
Minnie – Right so he authenticated you by using some series of security questions and then you could carry on with your conversation as long as you wanted.
Mickey – Right!
Minnie – So this is an example of a Stateful application.
Take for instance your home computer or laptop. You have to login once and then you can access everything on your laptop until you log out or the system restarts.
Mickey – Oh so what will be a Stateful service like a web application in real world
Minnie – To take a real-world example of a website. In a stateful application, it is fairly simple. You log in with your credentials and once you are authenticated, you can now browse through all the sections that you are authorized to. It is similar to logging in to your home computer once and then you can access everything that your user has access to.
Here the information about your authentication or session is stored on the server. And as long as the session is maintained, the server knows you and you can continue browsing the website without getting logged out.
Mickey – Yes
Minnie – This is how Stateful applications work. Think of the representative as the server
As long as you are talking to one representative, it is all fine. You are authenticated once and you can do the conversation as long as you need until one of you drops off or disconnects (session ends)
Mickey – That is fairly simple and straight forward
Minnie – Yes, it is simple, fast, efficient, but Stateful applications have their own disadvantages.
Mickey – What’s that?
Minnie – The difference between Logging to your home computer and a website is that the latter takes place on the internet, so imagine this as logging to a server that is somewhere remotely located.
Mickey – That’s true.
Minnie – Coming back to the call center example.
Suppose you are talking to the representative who has authenticated you. Imagine that he has to transfer you to the claims department. Now the new representative at the claims department asks you the same set of questions again to authenticate. Will that be okay?
Mickey – I think that’s for my security but definitely that would be annoying.
Minnie – Yes, Similarly, now, suppose the website you are accessing is a large e-commerce website. As it is huge with lots of services running, they do not want to keep everything on a single server.
Mickey – That’s very likely.
Minnie – Yes, and so they have multiple servers and there is a load balancer to route traffic among these servers. (Hope you remember the story of Load Balancer)
Mickey – Okay I got this
Minnie – Now for an end-user, it does not make much difference. You will still access the website using the URL. But at the backend, the Load Balancer can divert traffic to different servers based on the load.
Let’s take a simple example, an e-commerce website uses 2 servers Server1 and Server2 and there is a load balancer to distribute and balance the traffic.
Mickey – Okay
Minnie – When you visit the site, your request goes through the Load Balancer and it decides which server to send the request to.
Let’s say you visited the site and Load Balancer sent your request to Server1.
When you log in with your username and password, Server1 will check your credentials against the database.
Once you are authenticated, your logged-in state will be stored on Server1
Mickey – I am getting this.
Minnie – Now this is all fine as long as you stay on Server1.
Mickey – Yes, that’s true.
Minnie – Now, let’s say you sent the next request, say to add an item to your cart. Now this time the Load Balancer sends your request to Server2.
Mickey – So what happens here.
Minnie – Here we encounter the problem. If the application is Stateful, you will have to login again.
Mickey – That’s annoying.
Minnie – Yes, remember the example of you had to verify the security questions with every new representative.
Mickey – Yes, I can relate now.
Minnie – So that is the reason with today’s applications having microservices architecture and using multiple servers, Stateful applications may not work that well.
Mickey – So what’s the solution.
Minnie – Shall we go back to our example of the Call Centre and find the solution.
Mickey – Yes, this is getting Interesting.
Minnie – So you have seen case 1 where you called into the Call Centre and the representative validated you through security questions and it was all fine as long as you were talking to the same representative. As you were transferred to another representative, you had to authenticate again. That was a Stateful application scenario.
Now, imagine Scenario 2, after a Representative at the call center authenticates you, he gives you a 4 digit pin code which is valid for a specific time duration. You can talk to any number of representatives, you just need to provide this 4 digit pin to authenticate yourself with any new representative.
Mickey – That’s Awesome!
Minnie – Minnie, yes and you will have to re-authenticate only if you disconnect or the time limit of the pin code expires
Mickey – That makes sense.
Minnie – So here now we are talking about Stateless service or Stateless application
Mickey – Okay!
Minnie – So in Stateless services, instead of storing the information that you have logged in to the website on the server, it is possible to store it on your own computer. Like you had the pin code with you and not the representative. The pin gets saved to the backend Database and any new representative can validate this pin from the database
Mickey – I am now understanding this. A real-world example will make it concrete.
Minnie – Sure, When you log in to a stateless application, instead of just checking the credentials against the database, the server also generates a unique token. Which is usually a long sequence of characters, and sends this token to you with instructions for the length of time it will remain valid.
So when you send your next request, the token goes along with that.
Now the information about this token is present on the database instead of any specific server. So no matter which server your request goes, as long as you have the token and it is not expired, you can continue an uninterrupted session.
Mickey – I got it Now
The representatives in the example are servers.
In 1st case i.e. Stateful application, I was authenticated by the representative and could communicate with him as long as I wanted without having to re-authenticates unless one of us disconnects. The information about my authentication was with him (Representative)
And this works all fine. But in case he transfers me to another representative (server) I have to authenticate again.
But if its a Stateless application, Once I get authenticated by any Representative (server), a token is generated that is stored on the database and also provided to me (User). So if I get routed to a new representative (server) I just have to provide the token which is valid for a specific duration.
In this case, The information about my authentication i.e. token is with me.
Minnie – That’s Awesome.
Mickey – I feel so good. Thanks, Minnie.
Minnie – I am always here for you 🙂
about the author | more stories
References – https://www.wirehive.com/thoughts/understanding-cloud-services-stateful-vs-stateless/
