Curating

Digital Experience

for You

 
 
 
 
Blog:

Cloud Native Applications: Should You Go for Stateless or Stateful Services?

POSTED ON: August 17, 2020 TAG: Cloud Native, Digital Transformation

Stateless services have been the main choice for developers for quite a long time now. They use a stateless protocol due to many reasons. These include resiliency from failures, choice to scale processing capacity up and down to tackle traffic variances and build recovery strategies in the event of a failure. On the periphery, building a stateless microservice or web app may seem the right way to go, it is not mandatorily the best approach for cloud native applications and services.

When to Go for Stateless Cloud Native Applications?

Developers are well-acquainted of the two major benefits when building stateless systems. On the one hand, the programming complexity is minimized, as incoming requests are received, processed, and then forgotten. On the other hand, there is no need to maintain state.

By their very nature, applications deal with the state of things. This includes what they do – they create, update, and delete stateful items. The typical processing flow of a stateless process comprises of receiving a request, retrieving the state from a persistence store (a relational database), initiate the changes requested, store the changed state back into the persistence store(s), and later forget anything that happened.

In computing, a stateless protocol is a communications protocol in which the receiver doesn’t retain the information in any session and the receiver is usually a server. The client sends the relevant session data to the receiver in a manner that every packet of information transferred is understood in isolation, without context information from previous packets in the session. This property of stateless protocols makes them good enough for tackling high volume applications, increasing performance by removing server load caused by retention of session information. A stateless protocol doesn’t need the server to retain session information.

Challenges With the Stateless Approach

Though there may be a reduction in overhead related to not maintaining session state on the server, there may be costs related to delegating state management outside of the application, like by delegating the sole responsibility for state management to the persistence layer. The cost is often visible when the persistence layer slows down due to high contention. The persistence layer fails to have unlimited processing capacity. After the processing capacity of the persistence layer is exceeded, the application cannot go any faster.

Understand that the decision to use a stateless approach contributes to the persistence capacity limits and this happens when state management is delegated from the application layer to the persistence layer.

When Is It Time to Use a Stateful Approach?

Although our intuition tells us that maintaining state has a related cost with the potential for increased complexity, the perception arises due to us looking at the problem from the perspective of our existing way of doing things. This relates to our current approach for maintaining state across a cluster and our current relational create, read, update, and delete (CRUD)-based ways to handle persistence.

Let us now look at event-based persistence. We use the classic shopping cart scenario, where each change to the state of a shopping cart is persisted as a sequence of events. This is a stateful alternative and shares an events-first way of processing as well as persisting state changes.

series of shopping cart

The figure above is an example of an event log and shows a series of shopping cart state change events. The events are persisted to an event log stored in a database, as each event takes place.

Events are statements of fact, a log of things that occurred at some point in the past as well as a historical record. In the event log above, the events aggregate to show that your shopping cart consists of one item – Item 3254. While my shopping cart consists of two items, besides the billing address. Also, there is the other shopping cart that too reflects one item.

At any point in time, it isn’t difficult to ascertain the state of a shopping cart by replaying the events up until that time. You can even recover the current state of any shopping cart at a particular time. View the state for a cart at a specific time in the past. For instance, the above shopping cart shows two items at 08:24.

Note that the event log can also record the many shopping cart changes. For instance, you changed or removed an item from your cart. The other user altered one of the cart items. This showcases an example of types of historical data that is generally lost when using the traditional CRUD-based persistence approach.

Persistence may be defined as “the continuance of an effect after the cause is removed”. In the context of data storage in a computer system, this implies that the data survives after the process with which it was created has come to an end. For a data store to be considered persistent, it should write to non-volatile storage.

One of the benefits of persisting data using events is the possibility to record all the interesting events that happened over time, leading to the current state of each shopping cart. The event data, like altering or removing items, can be quite exciting for downstream data analytics.

Another event log benefit is that the persistence data structure is a simple key and value pair. In the example above, the key is user id, item id, and time. The value is the event data. As the event log remains unchanged too, events are insert-only. The insert-only approach minimizes the load and contention of the persistence layer.

Have You Made Your Choice?

When it comes to cloud native applications, considering the best approach depends on circumstances, especially when determining stateless vs. stateful systems. In several cases, the stateless approach is an acceptable solution, but there are an increasing number of scenarios where using a stateful approach will be a better option. Undoubtedly, this is true for the ever-rising demand for high performance, stream-based, and near real-time systems.

POSTED ON: August 17, 2020 TAG: Cloud Native, Digital Transformation

Leave a Comment

Your email address will not be published. Required fields are marked *