For a long time, stateless services have been the primary choice for developers. One of the reasons for using a stateless protocol is that it provides resiliency from failures, recovery strategies in the event of failures, and the option to scale processing capacity up and down to handle variances in traffic.

While on the surface building a stateless web app or microservice may be the right way to go, in some cases it is not necessarily the best approach for cloud native services. In this post, we’ll discuss the differences between stateless and stateful application design, as well as provide a path for additional exploration.

There are two key advantages when building stateless systems. First, the programming complexity is reduced. Incoming requests are received, processed, and forgotten. Second, there is no need to maintain state, and often the complexity revolves around maintaining session state, which typically involves replicating the session state across the cluster. This replication approach is used to maintain the session state when one of the servers goes offline.

In the last sentence of the Wikipedia definition of a stateless protocol, it states: “This property of stateless protocols makes them ideal in high volume applications, increasing performance by removing server load caused by retention of session information.” While it is true that the stateless approach does not have the overhead of maintaining session state, it does introduce processing patterns that have their own overhead and performance costs.

The term stateless is somewhat misleading. Applications by their very nature deal with the state of things — that is what they do, they create, read, update, and delete stateful items. The typical processing flow of a stateless process is to receive a request, retrieve the state from a persistence store, such as a relational database, make the requested state changes, store the changed state back into the persistence stores, and then forget that anything happened.

Sponsor Note

Lightbend is a leading enterprise software and services company helping Global 2000 companies stay ahead in the digital economy. Our customers gain competitive advantage from the scalability and resilience of stateful cloud native applications and “always-on” insights of real-time streaming data.

While there may be reductions in overhead related to not maintaining session state on the servers, there may be costs associated with delegating state management outside of the application, such as delegating the sole responsibility for state management to the persistence layer. This cost is often seen when the persistence layer slows down due to high contention. It may be true that it is possible to scale processing capacity at the application layer with the ability to increase or decrease the number of stateless servers; however, it is also true that the persistence layer does not have unlimited processing capacity. Once the persistence processing capacity is exceeded, the application often cannot go any faster.

It is important to understand that the decision to use a stateless approach has contributed to the persistence capacity limits, by delegating state management from the application layer to the persistence layer.

#cloud native #development #contributed #sponsored #cloud