Stateless and stateful

State is whatever a program has to remember to do its job: who is logged in, what is in the shopping cart, the rows of a database. A stateless component keeps none of that between requests. Each request arrives with everything needed to answer it, or the component looks it up elsewhere. A stateful component keeps that memory inside itself, in its RAM or on its own disk.

The difference matters a lot in the cloud. Stateless servers are interchangeable: a load balancer can send any request to any copy, autoscaling can add ten more during a spike and delete them later, and if one crashes nothing is lost. That is why the usual advice is to make web and API servers stateless and push the state into services built to hold it, like a database, a cache or object storage. HTTP itself is a stateless protocol; logins work because the browser sends a cookie or token with every request.

Stateful systems, such as databases, message queues or a multiplayer game server, are harder to run. You cannot just kill a copy or start a new one; data has to be replicated, backed up and moved carefully. In Kubernetes, for example, stateless apps use Deployments while stateful ones need StatefulSets and persistent volumes. The design goal is not to avoid state, which every useful app has, but to keep it in a few well-guarded places.