Stateless Application Servers

An application server is the machine that runs your code: it takes a request, reads and writes data, and builds the response. Keeping it stateless means it holds nothing about a user in its own memory between one request and the next. Every server is then interchangeable, so any of them can answer any request, and you can add or remove them freely.

What state means here. State is anything the server must remember to answer the next request correctly: who is signed in, what is in the basket, which step of a form the user reached. The data does not go away when a server is stateless. It moves to a shared store, such as a database or a cache, that every server can read.

What it allows. Because no server is special, a load balancer can send each request to any of them. A failed server is replaced without losing anything. When traffic climbs, a new copy starts and takes requests at once, without moving any data onto it.

What it costs. Every request that needs the state reads it from the shared store, which adds a round trip, a millisecond or less inside one data centre. The shared store now matters to everything, so it needs a spare of its own.

Where you meet it. Any web framework's process plays this part: a Node.js server, a Spring Boot application, a Django worker. Each is stateless when it keeps sessions and uploads outside its own memory and disk.

So move every piece of user state out of the application server's memory: that one choice is what lets the servers be added, replaced and removed without anyone noticing.