Stateless servers
Why any server must be able to answer any request, and where the state goes instead.
When you add a second server, a bug appears that did not exist before. A customer logs in on server 1, which remembers the login in its memory. Their next request lands on server 2, which has never heard of them, and the app says they are logged out. The problem is state stored on the server itself: sessions, shopping carts, uploaded files, in-progress jobs. A stateless server keeps nothing between requests that another server would need.
Statelessness does not mean the application has no state; it means the state lives somewhere shared. A request carries what the server needs (a session token or a signed token), and the server fetches the rest from a shared store such as a database or a fast key-value store. Then every server is interchangeable, the balancer can send any request anywhere, and you can add, remove or replace servers freely.
What to move out of the server
Step 1 of 4
Sessions and logins
Keep them in a shared store, or put them in a signed token the client sends back with each request.
Statelessness pays off beyond scaling. Deploys become routine because you replace servers one at a time. Autoscaling becomes possible because new servers are useful immediately. Failures are cheap because the replacement needs no memory of the old server. The cost is an extra network call to the shared store on each request, which is why those stores must be fast and themselves replicated.
Your turn
List five pieces of state in a food-delivery web server and say where each should live to make it stateless.
Stuck? Think about logins, carts, photos, driver locations and queued emails.
What to remember
State kept inside one server breaks as soon as there are two.
Stateless servers keep shared state in shared stores and carry identity in tokens.
Interchangeable servers can be added, replaced, deployed and autoscaled freely.
The cost is a network call to the shared store, which must itself be fast and redundant.