Welcome to my new blog sir, How can I help you? Before asking me anything you should know that there are two ways to serve you, and you should choose the one that you feel comfortable with, because I don’t like my guests to be bothered!
Stateful
In a stateful architecture, you design your apps to remember your clients. To translate this in the world of tech: Suppose you have a server that runs a stateful system and there are some clients that have opened a network session and started to use your system. In this context the stateful system will remember the clients by remembering their past interactions with the system and store their session data, this is very powerful! Because the system remember who you are, you can do less less work in the next new transaction you are going to do with the system. Let’s take an example of a stateful system in Facebook for example to understand this architecture more:
Suppose you are logged into your Facebook account. You have established a login session between you and the Facebook server! The server now stored your session data and remebered you
Imagine that you have seen your Ex-Partner posting a picture enjoying her life without you, So you’ve decided to react “HAHA” to her photo, once you sent the react to the server, the server already know who you are because it remembers you, so here the server doesn’t need to know who you are again to send the reaction to tease her because it already stored some information regarding your identity authentication and it uses it as lon as the session is alive! It will be horrible to authenticate and start a brand new session with the server each time you want to react to a post! Of course the authentication still exists for security reasons but in some other ways not like this!
You can now deduce that this architecture will be suitable and you will use it for systems that do an long ongoing periodic communication with their clients! Systems like: User-centric applications that establishes login sessions or in AI training that always uses the previous context of the data you submitted… You’ve gotten the main idea now.
These systems requires your clients to be more catious about their session because it maybe stolen and hackers can pretend that they are the authenticated client in some well-known hacks like cookies? hijacking. Of course this requires training the clients for the best security practices but in a critical systems you can do some security design best-practices to prevent that like “Risk mitigation” analyze malicious behaviours in the session using AI and analyzing logs, many practices can be used here, for example AWS does “key rotation” which is in very basic words changing the cryptographic keys that authenticate the client in the session.
Now let’s see how does this architecture in a system design figure!
In this stateful system, each client is connected to a specific server, each server is storing the session data of the client that is connected to it, if an outage happened in some server and it went out of service, so the client may be connected to other server of the available ones, but the other servers will not know this client because they don’t store thier session data it is gone with the died server.
In these faulire scenarios that your system should always consider, you must decide what your system will do whether it will establish a new session, so you will consider memory overhead that may occur on the other server due to the new sessions that will come to it to store and it maybe overwhelmed by the requests that are coming to it so you need to think about memory management techniques here, or is it a sensitive system then it must apply faullt resilience techniques that saves the session so your servers should apply some coherence protocols to ensure the integrity and good accesability of the data among all servers.
If you aren’t sure what are the coherence protocols, we have dicussed them before in this blog
Note that we are talking about the software design challenges only we didn’t come to the infrastrcture deisgn big problems that will requires you to think of proxies, replicas, load-balancer, etc… to resolve these problems. All of this introduces us to a really difficult challenge that you must know you will face in the stateful systems: The scalability.
Stateless
Stateless systems are like chill guy! They don’t remember who is the client, so they respond to all the client’s requests in the same way for all, whoever is the client they treat all the same way.
From this simple idea in the stateless architectures we can build great systems that offer the advantage of simplicity in everything: simplicity in building, simplicity in scaling, simplicity in using, etc..
To understand the nature of the statless systems let’s take the HTTP protocol for example, HTTP is a stateless protocol that means it doesn’t retain the session state from previous requests, which also means that every time you send a request to some server using HTTP you are going to send all the manifest to tell the server who you are and what exactly do you want in every request, you make you will start from the beginning telling the server who you are and what do you want!
That’s why if some client made several requests to the server, everytime you need to tell the server who you are. That’s why the server everytime gets fields like user-agent in the request. In stateful system you have to send it one time and it will remember it, but in the stateless no, everytime you do it. Also you can see fields like Accept which tells the server what type of content I can accept and deal with. Everytime these fields are sent because every request is totally independent from the other request. You can remember it like stateless are dealing with requests more than it dealing with clients.
So in these types of systems once the request is sent and you want to modify something in the request, you have to send a brand new one!
About the simplicity I have mentioned before, we can build many great applications that can scale very efficiently because they are more simple than the stateless, because if a client is dealing with server 1 in a stateless system it can deal with server 2 in anytime because the state of the client is not important (state-less), that’s why the scalability here is simpler allowing your system to grow efficiently and that’s actually a good option for some microservices to implement, some microservices uses RESTful APIs, using stateless architecture you can implement Serverless architectures which are implemented to make the systems response to events in isolation without retaining the context that’s a very good option for many services, it’s like having a service that is always running and waiting for some request to make some pre-defined action, for example you have a service that count the size of data the client is sending before sending it to the main server! I don’t care about the client I care more about the request here and this stateless service allows me to do this and it is very useful and reduced the load on the main server! Actually we have gotten a great example on this which is AWS lambda that runs your code only when needed. Great application comes from understanding simple core ideas!
Implementing stateless or stateful architectures to your application, depends mainly on your decision in chossing what exactly do you care and want to remeber? aka what’s the context? and other factors like any system in the world will consider: bandwidth, memory, cost, etc..