Stateless vs. stateful
Once you have many servers (scaling out), a sneaky problem appears: a user's first request might land on server 3, and their next one on server 7. If server 3 was secretly remembering things about that user, server 7 has no idea what's going on. The fix is a powerful idea: make servers remember NOTHING between requests. That's stateless — and it's why scaling out actually works.
Stateful = the server remembers you. Stateless = it doesn't.
A stateful server keeps notes about you between requests: "this is the person who logged in two clicks ago, with these 3 items in their cart." Convenient — but those notes live on THAT one server. A stateless server keeps no notes. Every request must carry everything the server needs to answer it — like showing your ID card fresh each time. The server reads the request, answers, and forgets you instantly. Sounds wasteful. It's actually the superpower.
Why forgetting is the superpower
Picture a coat check where only ONE specific attendant knows where your coat is. If they go on break, you can't get your coat. That's stateful — your stuff is tied to one server. Now picture a ticket: anyone holding the matching number can fetch your coat. Any attendant works. That's stateless — because the request carries the proof, ANY server can handle it. That's the magic: with stateless servers you can add a hundred machines and route each request to whichever one is free, because no request is glued to a specific server. Scaling out finally works smoothly.
But the state has to live SOMEWHERE
Here's the honest catch: "the servers remember nothing" doesn't mean the SYSTEM remembers nothing. Your cart, your login — that information still has to exist. We just move it OUT of the individual server and into a shared place everyone can reach: a database, or a fast cache, or a token you carry in the request itself. So stateless servers aren't amnesiac magic — they're servers that look up what they need from a shared store every time, instead of hoarding it privately. That keeps the servers interchangeable (great for scaling) while the truth lives in one shared spot (great for consistency).
It's a tradeoff
| Option | 👍 Pro | 👎 Con |
|---|---|---|
| Stateful servers | Convenient and fast — the data is right there, no lookup needed. | Each user is glued to one server. If it dies or you add more servers, things break or get complicated. |
| Stateless servers | Any server can handle any request — add/remove servers freely, survive failures. Scaling out just works. | The state must live in a shared store (DB/cache/token), and every request pays a small lookup cost. |
Questions you might have
▸Isn't forgetting everything a BAD thing?
It feels backwards, but no. If a server remembers you, you're stuck with that one server. If it forgets you, ANY server can serve you — so you can add a hundred of them and route freely. Forgetting is what makes a fleet of servers interchangeable.
▸If the server forgets, how does it know I'm logged in?
The information moves to a shared place: a database, a fast cache, or a token your request carries (like a wristband). The server looks it up fresh each time instead of holding it privately. The system remembers; the individual server doesn't.
▸What does 'state' even mean here?
State is any memory of what happened before — who you are, what's in your cart, where you were in a flow. Stateful = the server keeps that memory itself. Stateless = the server keeps none and reads it from a shared store each request.
▸Why does this matter so much for scaling?
Because scaling out means many servers and a load balancer sending each request to whoever's free. If requests were glued to specific servers (stateful), that free routing breaks. Stateless servers can be swapped, added, and removed without anyone noticing — exactly what scaling needs.
Best read after: Scaling up vs. scaling out