4

I've read this example which basically states that, since a method has to hold a single private field.. It is considered a stateful system.

So basically ANYTHING system that calls upon some sort of data-storage mechanism to retrieve something to serve a current request is a stateful system?

3
  • 1
    How do you define "stateful"? How do you define "system"? Without a definition of those two terms, your question is un-answerable. Aug 16 '20 at 7:02
  • 1
    A quick comment to complement other answers: when it comes to client-server interaction, statelessness usually refers to client-related state. A stateful server keeps some user-specific data and has to look it up to fulfill requests (e.g., "oh, this particular user completed step 3, respond with step 4"). A stateless server (in the aforementioned sense) pushes that responsibility on the client itself, so that it doesn't have to do such lookups; each user keeps their own state and sends it with the request ("I was on step 3, here's what I did, what's next?") Aug 16 '20 at 15:44
  • This makes the server scalable (you can spin up a bunch of new instances of the server-side application, as it doesn't matter which instance responds, since the request itself contains all that's needed to produce a response or an action). Now, the server(-side system) has enough knowledge baked into it to make sense of such requests (e.g., it knows there are, say, 5 steps total), and likely keeps it's own state that's related to its business functions, but isn't user-specific (e.g. a database of records, or some internal state that's not accessible from outside). Aug 16 '20 at 15:46
4

Words may be used for different purpose in different contexts:

For a class, the term stateless is used to describe the special case of absence of attributes and properties. A statefull class is in most of the cases just called a class. So statefull/stateless are about the internals of the class.

For a system such kind of distinction makes no sense. Any useful system has a state. For example:

  • an application with an empty window has at least registered itself to the windowing system and must know about the window. So there’s a state.
  • a backend that handles REST request must have opened some ports to listen to incoming request and must know what port it has opened, and if the port is already bound. So there’s a state.

For systems, stateless/statefull has only a meaning when talking about its interactions with the outside world, and more precisely its API:

  • if the API requires the system to store a state related to its requester, it’s statefull;
  • if the API doesn’t need to keep anything about the requester between two requests, it’s stateless.

So, to paraphrase a known SW pioneer, when it comes to terminology, premature generalization is the root of all evil ;-)

7

It depends on the context you’re talking about. Or more visually, how big the box named “system” is.

Since the DB (or cache, or external system, etc.) might change, it is stateful in that you can’t memoize the result and just ignore the DB from there on out. (Stateful is probably the wrong term here, but people rarely use terms properly around these sort of concepts.)

But if say... your API layer code has no mutable state, it can be considered stateless even though it talks to the DB. This is common, since it allows you to deploy a bunch of that code (and _un_deploy a bunch of that code) without worrying about coordinating or loading state.

3

I think it is worth to reflect on the terms stateful and stateless applications considering scalabilty in the context of distributed architectures such as Microservices.

In this context I consider an application (or service) to be stateless if there is no application state existing as part of the running process.

This means you can run several instances of the same application (service) to allow for horizontal scalability.

That means it does not matter to the client which is communicating with the application (service) which of the instances of the same application it is talking to.

As all state is externalized to other components (e.g. a database for persistent state) and is accessed by the application instances on demand the application itself can be considered stateless.

Consider the following example:

  • There is a traditional web application using sessions for user authentication.
  • The server side session is stored in the machine's memory the application instance is running on.
  • If there are several instances of the same application each instance has it's own session state.

Now consider you are running several instances of the same application. Some component (e.g. a load balancer) would now have to make sure that each client is always directed to the same instance of the application so that the corresponding session state is available.

With that you have a stateful application which could be turned into a stateless application e.g. by changing the architecture:

  • Externalize the session state to a shared session storage which is accessed by all applications (such as Redis Cache)
  • Use tokens (see also OAuth2) that are sent with each request containing the required authentication information

In both cases you are switching the application from stateful to stateless - at least for authentication state.

So to answer your question:

If a system talks to a database to get some previous information to serve a request, does that make the system stateful or stateless?

An entire system can be considered stateful in this case but different parts of the system (e.g. services) can still be considered stateless as described above.

I would consider an entire system to be stateless if I would deploy the same system with all it's components completely independent from other system instances of the same type. And in addition it should not be necessary to keep any state in the system instances to function properly no matter if a client talks to system instance A, B, C, etc.

1
  • nice example on session storage
    – lennon310
    Nov 25 '20 at 14:08
2

Stateful vs stateless

since a method has to hold a single private field.. It is considered a stateful system.

I think you're getting bogged down by technical implementation details in your understanding of what is stateful/stateless.

For example, take this conversation:

A - Who is the 44th President of the United States?
B - Barack Obama
A - How old is he?
B - 59

You can imagine that A is your end user and B is your application/system and that each question/answer pair represents a single (web) request.

Notice the "he". This second question only makes sense if you remember the first question. Without remembering the first question, you wouldn't know who "he" is.

You would not be able to ask each question to a different person, as the person receiving the second question would need to know who "he" refers to.

This is an example of a stateful system. It needs to remember certain things (previous questions/answers) in order to process additional questions.

Compare this to:

A - Who is the 44th President of the United States?
B - Barack Obama
A - How old is Barack Obama?
B - 59

Either question makes sense on its own. They could've been asked in a different order, or to different people, or ...

Each question is a self-contained unit, and doesn't require any memory of previous questions/answers.

This is an example of a stateless system. Each question stands on its own, no one needs to remember anything.


State in programming

In programming terms, "state" is therefore generally equivalent to "stored data" (arguable caveat: excluding compile-time constants). This is why your example suggests that state is represented using a field. That's not a complete truth, though.

It depends on what we're talking about. When we are considering if a class is stateful/less, then we focus on fields and auto-properties (since they have backing fields).

But when you're talking about a system/application being statefull/less, it doesn't matter whether you have fields or not. What matters is that the system/application stores and retrieves data. Whether that's field, in-memory, file, database or cloud storage is completely irrelevant.


Your question

If a system talks to a database to get some previous information to serve a request , does that make the system stateful or stateless?

It depends on whether the database is considered to be part of the system or not.

If the database is part of "the system" we're talking about, then the system is stateful, since it must clearly be using the database to store (= remember) data.

If the database is not considered part of "the system" we're talking about, then the system is stateless (of course assuming that it doesn't own any other data stores either)

An example of such a "database not part of the system" example is SQL Server Management Studio. While it provides easy access to a database and its contents, the application itself does not host or maintain any database (or database server) itself. Instead, you tell it which existing database (or database server) to connect to. That means that SSMS (the application, its codebase) does not include any database in and of itself, and it is (in this specific regard) stateless, not stateful.

Another example: any application that has an options panel is effectively a stateful application, as you expect the application to remember and respect those settings when you interact with it.


Scalability

Slightly more different from what has been mention up until now, most commonly "stateful"/"stateless" is being used when considering scalability.

In this case, it's not a matter of whether a system owns a data store, but rather if a system is expected to keep track of a context which observes multiple chained requests.

Going back to our Barack Obama example, whether you have a stateful or stateless approach matters for your scalability.

In a stateless system, you can deploy your application to many different servers to increase the system's capacity, and you don't need to worry about anything going wrong. Each request (question) is self-contained, and every individual server is able to handle every individual request.

In a stateful system, you're going to have to take care to track your state correctly. For example, if you deploy your application to multiple servers, then your "how old is he?" question should only be sent to a server who is aware that you first asked who the 44th president is.

This can be done in one of two ways:

  • A user's subsequent requests forcibly get routed to the same server that handles the first request. This is called "sticky sessions". However, this can mess with your load balancing and scalability.
  • All servers can share a context in which they track the state of each user's requests, therefore any server knows what the previous questions were. However, this now creates a bottleneck by having all distributed servers rely on this singular state; which means that your scalability is gets hindered more and more as you scale your service up more and more.

Both of these approaches detract from your scalability. In order to maximize scalability, you want your setup to be stateless as much as possible.

Generally speaking, read operations (fetching data) are commonly stateless and can easily be scaled up or down, whereas write operations (storing data) generally require some change tracking or bottlenecking to avoid race conditions and write conflicts, which means that it can't be scaled up as easily as the read operations.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.