Having a firm grasp on the concept of stateful and stateless services is essential not just for working with Service Fabric, but for understanding distributed software systems generally. State is such a fundamental and ubiquitous concept that I would even recommend more experienced programmers sit through this brief lesson just for review. 

So let's talk about state. What do we mean? In the software world, state simply refers to data. So when we say something is stateless, we mean that it does not retain data. A stateless service is like a black box. It takes an input and uses that input to create an output. What goes on inside may or may not be visible to us. The thing that makes it stateless is that the output is in no way a function of some existing state or data in the service. The output is instead 100% a function of the input. 

Now, by contrast, a service is stateful when it must make use of some existing data. In other words, the service has a memory. Its output is not 100% the function of an input. In order to function, the service needs to retain and access some set of stored information over some period of time. 

Now, I've been using the word service here because our main concern is web applications, but it's important to understand that these terms stateless and stateful are broader than that. Other things can have a concept of state. For example, protocols. HTTP is a stateless protocol because each message is an isolated unit. There's no need for the web server to retain any memory to process individual messages. FTP, however, is a stateful protocol. It relies on session data that validates information about a user over time, and it relies on this to process requests. 

So let's return to our focus to services. Azure's own documentation covers this idea pretty well, and it's worth reviewing. We'll link to it (https://docs.microsoft.com/azure/service-fabric/service-fabric-reliable-services-introduction).

Now, in their documentation, they give the example of a calculator as a stateless service. All the input comes directly from the user. The calculator takes it and computes a result and then outputs it. Now, this is a good example, but as they point out, it's not really true to how most stateless services in real cloud architectures. For most companies, a production software service is not totally stateless. Rather, it simply externalizes its state to some other storage system. For example, a web app that relies on something like Redis to cache session data is not truly stateless. 

A stateless service may depend on other stateful services. A web front end that receives requests from clients and then forwards those requests to stateful back end services is an example of this. From that web front end's point of view, its outputs are entirely a function of its inputs. How it processes a user or client request is entirely a function of that request. When it receives a response from a back end service, again, how it processes that response and what it returns to the client or user is entirely a function of that response. Now, this is a very common paradigm in Service Fabric, this decoupling of, say, a front end from stateful back end. 

The state we will mostly concern ourselves with in Service Fabric will not be from external stores like a database or cache system like Redis. Instead, we will use something known as Reliable Collections. Now, by collections, we're referring mainly to queues and other forms of local state storage. There are a lot of options here within Service Fabric, and we will cover this in depth in the lesson after the next one. Service Fabric can also make use of traditional databases and file storage if necessary. However, this is often not as efficient as using Service Fabric's own Reliable Collections API. 

The sample project we'll build in section three will include both stateless and stateful components and the use of Reliable Collections. This will help you to understand both of the different paradigms in the context of Service Fabric. 

That about wraps it up for this section. Hopefully you have a solid grasp of this concept now. We will review a little bit in section three, so don't sweat it if you're still a little unsure. Feel free to also review Azure's documentation or rewatch the lesson until the examples make sense. If you're ready, we'll move on to part three of this section and learn about the actor model. See you there.