Stateful and Stateless Applications

Stateful 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 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, hence it is faster. But it does have drawbacks. Let's say there is a load balancer and there are two servers behind, running same Stateful application. Now first request to login go to server 1 and second request might go to server 2, now since only server one has enabled login to 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.

While Stateless applications work in different ways. They don't store any state on the server. They use DB to store all the Info. Obviously, DB is stateful, i.e. it has persistent storage attached to it.

Typically, a user request for login with credentials, any of the server behind LB process the request and generates an auth token and stores it in DB and returns token to the client on the frontend. Next request is sent along with 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, doesn't have any link with previous or next request, 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.

Stateless or stateful which one is good

Nowadays stateless is recommended architecture as compared to stateful because of following reasons

• In the case of stateful applications, the user can able to open lots of incomplete sessions and transactions. which become bit overhead for the server
• The server cannot able to verify if the client is crashed or disconnected
• Nowadays applications use separate deployments for client side and server side. In the client side, it uses client-side technology languages such as angular, react ...etc. So it is tough to maintain do a stateful session here

Stateless application working

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 grow 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.' While distributing 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 'previously stored state' of the client. The state information sent along with each request, to the server through which 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. 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.