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?
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.
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:
For systems, stateless/statefull has only a meaning when talking about its interactions with the outside world, and more precisely its API:
So, to paraphrase a known SW pioneer, when it comes to terminology, premature generalization is the root of all evil ;-)
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:
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:
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.
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.
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.
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.
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:
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.
