# Stateless and stateful

> Whether a program remembers things between requests, or keeps that memory somewhere else.

- Level: Intermediate
- Topics: Cloud, Software
- URL: https://tidbit.legios.com.ar/stateless-and-stateful/
- In Spanish: [Stateless y stateful](https://tidbit.legios.com.ar/es/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.

## An analogy

A stateless server is like a cashier at a supermarket: any free cashier can serve you, because everything they need is in your cart. A stateful one is like your family doctor, who remembers your history, so you have to see that specific person.

## Keep in mind

- Stateless: remembers nothing between requests; any copy can answer.
- Stateful: keeps data inside itself, so that copy matters.
- Stateless servers scale and recover easily behind a load balancer.
- Common design: stateless app servers, state kept in databases and caches.

## Go deeper

- [Stateless protocol on Wikipedia](https://en.wikipedia.org/wiki/Stateless_protocol)
- [State (computer science) on Wikipedia](https://en.wikipedia.org/wiki/State_(computer_science))
- [The Twelve-Factor App: processes](https://12factor.net/processes)

## Related terms

- [Database](https://tidbit.legios.com.ar/database/): An organized store of data that programs can search and update safely.
- [RAM](https://tidbit.legios.com.ar/ram/): The computer's short-term memory: fast, small and wiped when you turn it off.
- [Cloud computing](https://tidbit.legios.com.ar/cloud-computing/): Renting computers over the internet instead of buying your own.
- [Server](https://tidbit.legios.com.ar/server/): A computer whose job is to answer requests from other computers, all day, every day.
- [Load balancer](https://tidbit.legios.com.ar/load-balancer/): The traffic cop that spreads incoming requests across many servers.
- [Autoscaling](https://tidbit.legios.com.ar/autoscaling/): Adding and removing servers automatically as demand goes up and down.
- [API](https://tidbit.legios.com.ar/api/): The menu of things one program lets another program ask for.
- [Caching](https://tidbit.legios.com.ar/caching/): Keeping a copy of an answer close by so you do not have to work it out again.