top of page

Be careful with your state

One of the hardest aspects of a cloud native application design is to decide whether application component or service should be Stateful or Stateless.

Stateful components remember specific details of the users, like the user profile, preferences or user actions or remembers a system state, like how many instances of the component are running or the history of system statuses.

All this information is considered a "current state" of user or of a system. Some systems store this data within a caching tier or on the application server itself. Stateful service might still have a back-end database but it will not use it to process user requests. When we have all this information available, this is greatly speeds up the request processing.

Stateless components do not save any client data on the application server. They receive the request, retrieve the user state from the back-end database, do the required changes, save the changes to the database and forget anything that have happened. Its not that they do not have a state, they simply store it inside the back end database.

Stateful processes do not need to call the database if the same user comes back because all info stored on the server already, which means very fast request processing. Caching layers are usually much faster than the relational databases. Every client request happens with the context and can be affected by what happened during previous transactions. When your transaction was interrupted, you will be able to continue where you left off. However, its almost impossible to horizontally scale stateful applications; application server restarts and memory warm ups can be potentially quite long and application server must be powerful enough to handle the traffic.

Stateless applications are much more resilient to failures because you always can spin up an additional instance of a service. They are easy to scale because you simply add more copies of the service. Stateless applications are highly available and reliable and you can make sure they terminate after finishing with their current task. This means infinite scalability when we can handle any number of requests. The downside can be felt when the persistence layer ( database) slows down due to high contention of the resources / high concurrency of the requests. In such scenario, database becomes an application performance bottleneck. We need to chose database wisely, making sure it can scale alongside the application.

The majority of the on-prem hosted applications are stateful. However, the more we advance into the cloud, we should consider architecting the cloud native application components that are stateless unless there is a reason to have state. Containers and endless cloud resources make going stateless easier because containers were by design built to be portable, flexible and stateless.



Get New posts delivered straight to your inbox

Thank you for subscribing!

bottom of page