Stateless services

The state problem

Run the round-robin setup from lesson 2-2 with real users and something breaks immediately: logins.

State is any data a server remembers between requests. The classic example is a session: after login, the server stores "session42 belongs to ada" so later requests with that session ID are trusted.

If server A stores that session in its own memory, and the load balancer sends ada's next request to server B, then B has never heard of session42. Ada is suddenly logged out, but only sometimes, depending on where the LB sends her. These bugs are miserable to debug.

A service is stateless when any server can handle any request, because servers keep nothing important in local memory. Stateless services are what make horizontal scaling safe.

Where state goes instead

Three standard homes for state that used to live in server memory:

1. The database. Anything durable (users, posts, orders) was already here
2. A shared in-memory store like Redis: a tiny, very fast key-value database all app servers share. Perfect for sessions. You will meet Redis again as a cache in unit 3
3. The client. Signed tokens (like JWTs) let the browser carry its own proof of login, so servers store nothing

Some things resist this, like websocket connections for live chat, and we will handle that honestly in the chat capstone (lesson 10-2).

The unit 2 recipe, used by nearly every web backend on earth: load balancer, N stateless app servers, shared database and session store.