Stateless
stateful, statelessness, stateless protocol, stateful serviceDefinitions
Stateless — every request carries everything needed to serve it, and the server keeps nothing about the caller between requests; HTTP is stateless by design, which is why a cookie or a token has to be sent again each time
Statelessness is what makes a service horizontally scalable: if no instance remembers you, any instance can serve you, and one dying costs nothing. Everything a session needs is either in the request or in a store both instances can reach — which relocates the state rather than removing it. That relocation is the whole design decision.
Stateful — the counterpart: an instance holds something about the caller between requests, such as an open WebSocket, an in-memory session or a local cache
Not a failure mode; a trade. Stateful is how you get a live connection, a warm pool or a cheap cache, and the cost is that the caller must keep reaching the same instance — sticky routing, a harder deploy, and real work to lose when that instance restarts.
A pair, and the question they answer is: can any instance serve this request, or only the one that has been serving it?
Avoid: calling an application stateless because the code holds no variables. The state is in the cookie, the token, the database and the cache; stateless describes where it does not live, which is in the process.