What are Stateful and Stateless applications?
Stateful and Stateless applications store state from client requests on the server itself and use that state to process further requests. It uses DB for storing data as a backend, but session information stored on the server itself. When a user sends a login request, it enables login to be true and user authenticated now, and on the second request, the user sees the dashboard. Stateful applications don’t need to make a call to DB second time as session info stored on the server itself.Microservices applications
Hence it is faster. But it does have drawbacks. There is a load balancer, and there are two servers behind, running the same Stateful application. First request to log in go to server one and second request might go to server 2; now, since only the server has enabled login to be true, the user won’t be able to logic when LB sends him to 2nd server. So it’s not possible to horizontally scale Stateful applications.
Stateless and stateful container management
While Stateless applications work in different ways, they don’t store any state on the server. They use DB to store all the info. DB is stateful, i.e., it has persistent storage attached to it.
Typically, a user requests login with credentials, any of the servers behind LB process the request, generates an auth token, stores it in DB, and returns token to the client on the front end. Next request is sent along with the token, Now, no matter whichever server process request, it will match the token with info in DB, and grant login to the user. Every request is independent and doesn’t have any link with previous or next requests, just like REST.
Although Stateless apps have one extra overhead of the call to DB, these apps are amazing at horizontally scaling, crucial for modern apps, which might have millions of users.
Modern applications and legacy applications have one characteristic in common, whether to store state or not. Whether dealing with Monoliths or microservices depends on the application needs’; some need to store state while some don’t need to care about the state.
Difference between Stateful vs. Stateless applications
Both Stateful and Stateless omnipresent in IT shops. But modern software being architected in the Stateless manner since scaling is an essential factor for today’s world.
The eight main differences between Stateful and Stateless applications are –
- State of working: Applications in Stateful react by the current state, while Stateless applications act independently with taking into consideration previous/next request.
- Stored Data: If the webserver stores data in a backend manner and uses it to identify the user as an always-connected client, the service is Stateful. While in Stateless, the server does store data, but in a database to verify user/client whenever it needs to connect.
- Reaction toward Clients: In Stateful, the server thinks a client is just a dumb machine, while in Stateless, server things the client is an intelligent machine that doesn’t need to depend on any state on the server-side.
- Requests: In Stateless, requests are self-contained, i.e. everything contained within the request, and handled in two distinct phases, a “request” and “response.” While in Stateful, requests always dependant on the server-side state.
- Generated State: While browsing the internet, the state generated and stored somewhere. Although the state generated in both types when the state stored on the server, it generates a session. This is called a Stateful application.
- State Stored: When the state stored by the client, it generates some data used for further requests while technically “Stateful” as it references a state, but the state stored by the client, so call it Stateless.
- Cookie Stores: On the client-side, cookie stores authentication data. On the server-side, create temporary client data or store on a database(this is the typical case). While returning to the dashboard to make another payment, it’s a cookie stored in the browser that establishes the state with the server.
- User Base: Stateful is past when there were Monoliths and no dynamic user base. Stateless is future, having Microservices floating around and mostly communicate through REST interfaces and scale-like anything since there is no state stored.
Moving to microservices and containers helps enterprises seeking to move past legacy technologies, but challenges still remain.
Source- Stateless Vs. Stateful
Why Stateless Applications Matters?
- Why is there a need for Stateless applications when things ran fine before with Stateful applications?
Stateful apps are excellent for minimal use cases, but it has some issues. First, when the user references a state on the server, the user opens a lot of incomplete sessions and transactions happen.
- In a Stateful system, the state calculated by the client, how long should the system leave the connection open?
- How to verify at the server-side that the client crashed or disconnected from the session?
- How the actions of the user tracked while maintaining the document changes and doing rollbacks?
Most consumers/clients respond to the server in intelligent, dynamic ways, thus maintaining a server state independent of the client assuming the client is merely a “dumb”; the client is wasteful.
Statelessness is a fundamental aspect of modern applications – every day; it uses a variety of stateless services and applications. It uses HTTP to connect in a stateless way, utilizing messages that are rendered and working within the isolation of each other and client state.
Facebook continually uses a stateless service. When the server requests a list of recent messages using the Facebook API, it issues a GET request with token and date. The response is independent of any server state, and everything is stored on the client’s machine in the form of a cache.
Similarly, invoking a POST command, pass a complex body with authorization/authentication data in the header without considering the server state.
There is no relationship with the previous, current & next request. In Stateless, the client does not wait for synchronization from the server. There is no process completion concept in serverless. So it’s faster.
REST is a mainstream way of designing, architecting, and developing modern APIs & Representational State Transfer (REST) is stateless.
How Stateless Application Works?
Stateless Architecture means the app is dependent only on Third-party storage because it doesn’t store any kind of state in memory or on its disk. All data it needs or requires has to fetch from some other stateful service (Database) or are present in the CRUD request. Requests load balanced to any replica of a stateless service because it has all data stored somewhere else, usually DB with persistent storage.
Stateless Architecture is entirely different and better than Stateful. Stateless applications scale very poorly.
When the volume of concurrent users grows in size in Stateful applications, more servers run the applications added, and load distributed evenly between those servers using a load-balancer. But since each server ‘remembers’ each logged-in user’s state, it becomes necessary to configure this load balancer in ‘sticky-mode.’ At the same time, distributing the load across servers, the load-balancer required to send each user’s request to the same server that responds to that user’s previous request, to process the request correctly, which defeats the purpose of load balancing because load not being distributed in a true Round-Robin fashion.
The server-side logic coded in such a way that it does not depend on the ‘previously-stored state’ of the client. The state information sent along with each request, to the server through which the server proceeds with servicing the request. Load-balancer doesn’t need to worry about routing requests to the same server, and truly uniform load balancing achieved. The load balancer sends traffic to any server & request serviced well since client sending token or other needful info with each request. JSON Web Token (JWT) widely used to create Stateless applications.
Benefits of Stateless Applications
The following are the 5 major advantages of the stateless application are below:
- Removes the overhead to create/use sessions.
- Wickedly scales horizontally needed for modern user’s needs.
- New instances of an application added/removed on demand.
- It allows consistency across various applications.
- Statelessness makes an application more comfortable to work with and maintainable.
Additional Scaling and Performance benefits of Stateless applications are below:
- Reduces memory usage at the server-side.
- Eliminates session expiry issue – Sometimes, expiring sessions cause issues that are hard to find and test. Stateless applications don’t need sessions & hence they don’t suffer from these.
- From the user’s side, statelessness allows resources to be linkable. If a page is stateless, then when the user links a friend to that page, it ensures the user views the same as another user viewing.
How to Adopt Stateless Applications?
The following are the 5 steps to adopt Stateless Applications
- Adopting Stateless applications can be a daunting task at first since it’s a new paradigm. But with the right mindset and information, adapt and develop new applications without keeping any state. Use Authentication/Authorization to connect to the server.
- Develop applications using the Microservices approach and containerization for deployment purposes. Containers are best at running stateless workloads. When several containers to manage the increase, consider switching to Orchestration and Management Tools such as Kubernetes to run a large number of Containers.
- Containerized Microservices applications find the best location to run Container from a resource point and maintain the HA (High Availability) of the application.
- Storage attached to Stateless is ephemeral. Organizations must begin with Stateless Containers as they are more easily adapted to this type of architecture and separated from Monolithic applications and independently scaled.
- The backend should use REST design patterns for building applications. REST philosophy is not to maintain state, only slightly cookies and local storage at the client-side.
Best Practices For Stateless Applications
Nine simple practices for proper maintaining Stateless Applications are below:
- Try to Avoid sessions at any cost.
- Sessions add unnecessary complexity providing very less value.
- It becomes difficult to reproduce bugs.
- Hard to fix session related bugs as everything is stored on the server-side.
- It’s not possible to scale sessions.
- If the load on application increases exponentially, distribute the load to different servers. If using sessions, replicate all sessions to all servers at the same time. The system becomes highly sophisticated and error-prone. Avoid sessions.
- Sessions are only useful for specific use-cases such as FTP (File Transfer Protocol).
- For use cases such as shared Dropbox, stateful sessions add additional overhead, while Stateless perfect way to go.
- Sessions functionality replicated using cookies, caching on the client-side.
Explore more about Microservices with Golang – A Complete Solution
Stateless Applications Tools
The best Stateless application tools are below:
- Modern languages such as Python, Golang.
- For deployment purpose – Containers and Orchestration such as Docker and Kubernetes.
- Other Services Discovery – Kube proxy service, Etcd.
- API Gateway – To connect to various services from outside.
- For Service Mesh around all Stateless applications: LinkerD / Istio.
Concluding Stateless Applications
Most IT companies that build Microservices, already creating Stateless applications using REST API design. Understanding this concept is the foundation on which most modern architectures are based on, such as concepts such as RESTful design. A good understanding and advantage of Stateless over Stateful is essential in developing applications to serve today’s users’ massive needs.