Stateful vs. Stateless

What’s a Network Protocol?

A network protocol is a set of rules for formatting, processing and transferring data between devices in a network. Devices on both sides of a communication exchange must accept and follow protocol norms in order to send and receive data correctly.

Network Protocols can typically be categorized into two types: Stateless and Stateful

Application’s State

The state of an application is the state of the program at a given time, with regards to the data that is stored for the application use. All the stored information, at a given instant in time, is called the application state and it is stored in memory on the server and it includes data for all its users.

Apps can be stateful or stateless, and these are differentiated on the basis of the requirement of server or server-side software to save status or session information.

Stateless Protocols

The client sends a request to the server and the server responds back according to the current state. It uses less resources since the receiver must not retain or save session information from previous requests.

Examples: 

  • HTTP (Hypertext Transfer Protocol)
  • UDP (User Datagram Protocol)
  • DNS (Domain Name System)

Stateless Application

In a stateless application, the session data is not stored on the server but rather locally on the end user’s device (for example in a form of website cookies) and is then passed to the server as needed. There is no stored reference to past transactions.

Stateless applications use content delivery network (CDN), web, or print servers to provide one service or function at a time.

Stateless apps can be connected to other apps through application program interfaces (APIs) and can be redeployed easily in the event of a failure.

Example:

  • Online search

Stateful Protocol

The receiver may retain session state from the previous requests; they require backing storage. If a client delivers a request to the server in a stateful protocol, it expects a response. If it does not receive a response, it will send the request again.

Examples:

  • FTP (File Transfer Protocol)
  • Telnet 

Stateful Applications

Stateful applications save session data to persistent disk storage for use by the server, by clients, and by other applications in the next session. The client data can be stored locally or on a remote host until the user logs out or the session expires. 

A current transaction may be affected by what happened during previous transactions, therefore stateful apps use the same servers each time they process a request from a user.  

The majority of applications that we use today are stateful.

Example:

  • Online Banking
  • Email

Stateful vs. Stateless in Container world

A few factors need to be taken into consideration at the time of choosing between stateful or stateless architecture. The type app that is being built, its use, purpose and the way the information should be transmitted.

Stateless architecture is best for apps where the information does not need to be stored, and has to be transmitted quickly and processed on the spot. 

Stateful architecture is best suited for apps where what happens during the first session may affect what happens during the next session, therefore information about what happens between sessions needs to be saved.

But when do Containers come into play? 

Stateless applications could be characterized by features such as easier scalability, an easier backup and quick disaster recovery. However, a mix of Stateful + Stateless approaches can be possible with the use of containers.

Containers are standard units of software that packages up code and all its dependencies so the application runs reliably and predictably even when from one computing environment to another. 

Originally, containers were not designed to save state information, hence statefulness was not possible. They were meant to perform operations in a flexible manner, no saving of state information required.

Many of the applications being deployed in containers today, are stateful and were not written with containerization in mind. But as containers have grown in popularity, existing stateful apps started being containerized giving them the flexibility and speed of using containers, but with the storage and context of statefulness. 

This merge has made stateful and stateless applications look very similar to each other. There can be a stateless app that does not require long-term storage, but still allows the server to track requests originating from the same client by using cookies.

Statefulness has become a major part of container storage. Currently it is possible for a container to be stateful with the help of drivers and integrations that provide persistent storage for containers, including databases for storing container state information.

Kubernetes made it possible to manage both stateless and stateful applications running in containers with Persistent Volume Claims (PVC), Storage Classes and CSI – Container Storage Interface providing support for common network and local attached storage.

The question is no longer IF to use stateful containers, but WHEN they should be used.

To learn more about Kubernetes and Containers check out our other articles.