Stateful and Stateless Softwares

To explore this topic meaningfully, we must first grasp two foundational concepts.

First, we need to separate an application from a system. A system contains and is composed of one or several applications. A system is a larger, more encompassing entity.

Second, we need to understand what we mean by “state” in a software application. This is a very abstract concept and a highly flexible topic in my experience. In different conversations, a state can refer to different things, often bending the bookish definition, yet experienced software engineers always intuitively understand what the state is being referred to in context.

In essence, state means information, information that our system relies on and which dictates how the system functions or behaves. The software relies on the state being there. A state may be simplified to information that gives meaning to the software’s function and purpose, essential to its functioning at runtime.

Examples to Understand State

Some relatable examples can help clarify the idea of state:

• When we interact with a software, like an operating system or computer, we log in to our user account. The system stores and remembers the user account and how you configured it for yourself, what wallpaper you set up, what and how many icons you put on the desktop, and things like that.
• Similarly, for an e-commerce application on the internet, you log in and add things to your cart or wishlist. Even if you refresh the page, you are not logged out, and the things you added are intact.

All this information that is persisting while giving purpose and meaning to the interaction between the software and its user is called state. The software remembers the user and related information between different interactions, identity information, actions like adding things to the cart, saved addresses, etc. The system practically cannot function or will have no meaning without this information or as we call it, state.

How is the State Stored? The key question.

Now comes the central question.

If state is critical to software functioning, how is it stored, and how does the system access it?

This is what determines whether the entity in question is stateful or stateless.

An application that stores the state itself, locally, will remember the critical information it needs by itself. This makes it stateful, it contains the state, it holds the state.

On the other hand, if it consumes or relies on the state from outside, the application becomes stateless. It does not hold the state. It still functions based on the state, but it’s supplied to it from outside. The application can run without it but it will have meaning only once it receives and processes the state.

Now this is where definitions start to blur in real-world scenarios. A stateless application can run without the state but it has no practical meaning so is it still technically stateful? It’s a thought worth pondering.

My two cents on this

Practically, what the stateless application offers us is the ability to work independently of the state. We can change the state and the system behaves differently. Or we can change the instance and supply it the same state, and it will do the job just fine. We can relaunch it from scratch and the user won’t know. For the user, everything remains the same since what’s giving the software meaning to him is still intact elsewhere and the new instance of the application still behaves the same way when it’s supplied that state.

Technically, the need for state does not define stateful or statelessness. It’s the ownership of the state and the ability to persist the state across invocations that decides that.

“A stateless application does not necessarily mean it’s state-free.”

More examples

Example: If the server stores the identity information locally, it’s stateful, whereas, if it stores it in a dedicated database, it itself has become stateless.

This is where the distinction between a system and an application comes into picture again. Although the application has become stateless by offshoring the state to the database, the system, consisting of both the server and the database, is still considered stateful.

From the system’s point of view, it still relies and functions based on some information (state) stored somewhere inside of the system itself.

A Simple Illustration of Stateful and Stateless Application

Since such information is almost always present in most software at the architecture level, stateless systems are very rare. However, stateless applications are very common.

“Truly stateless systems, especially complex ones, are rare”

A critical question

Now the natural next question in the series comes:

If the state is super critical to the application’s functioning, serving like the memory of what’s important and what gives meaning to the application and now that it’s stored outside of it, what and how does the application remember what to do and how to behave?

The answer is: the application does not remember anything.

“Stateless Applications remember nothing”

That’s the whole purpose and meaning of being stateless.

With every request that comes to the application now, that request has to either contain everything, every piece of state required by the application to process the request or contain a way to get this state, maybe an identifier of sorts that signals where the state can be obtained from.

Example: Many times, JWT is implemented to make the application stateless. In that case, the JWT contains all the information, and it’s required to be sent with every request.

Protocols as Examples of Stateful and Stateless Software

Some examples could include protocols, as protocols are also pieces of software.

TCP is a stateful protocol because it relies on all sorts of information like sequence numbers and connection status. Without this information, the connection can no longer function and will be reset or dropped.

DNS is stateless. The DNS server that implements the DNS protocol, by specification, does not store or remember anything. It works solely based on the information received in the request. It uses something called a Transaction ID (or Query ID) so that clients can match a request with its response, since the DNS server does not track the interaction and hence does not remember anything.

QUIC is a stateful protocol built on top of UDP, which is stateless. QUIC maintains its own state, using a Connection ID and other metadata for communication continuity.

Frontend Applications and State

The concept of state is present and strongly prevalent in frontend web applications as well.

For example, applications built using frameworks like React and Vue can have state storage in 3 levels:

• Component level (react component state variable and other mechanisms)
• Global level (Redux, Context API)
• or browser storage (LocalStorage, SessionStorage, IndexDB etc)
  The frontend app components can be built purely as stateless components working purely based on the props or they can have state managed by themselves within their lifecycle.

A frontend application does require things like authentication tokens, user preferences, scroll positions to be saved within the app lifecycle for proper functioning and meaningful and performant experience and to maintain continuity between user interactions. The application can be engineered to be supplied with all of this data with every interaction from outside, making it stateless.

Some cases where frontend can be said as purely stateless are

• Content served purely via SSR
• Static site generators
• Where no user login, no interactivity or personalisation is required
• A frontend acting as a shell over the backend, where the entire UI configuration is received from the backend, end to end, and the frontend just renders it

Final Thoughts

Understanding the difference between stateful and stateless software is essential in both architectural design and implementation. The concept is applicable across frontend, backend, and even at the protocol level.

Whether an application stores the state or relies on it externally affects its scalability, reliability, and complexity. Most systems are stateful at a macro level, but stateless components or applications within them allow us to build more modular, scalable, and easily maintainable systems.

In short, it’s not about removing state, it’s about managing state wisely.