Stateless Services & Session Handling
You'll learn to
- -Explain why storing session data on the server breaks horizontal scaling
- -Know the two common fixes: shared session stores and tokens
Everything in this module has been building toward one practical question: if a user logs in on Server A, and their next request gets routed by the load balancer to Server B, how does Server B know who they are? Get this wrong, and horizontal scaling breaks in a way that's easy to miss in a demo and painful in production.
The Anti-Pattern: Sticky Sessions
One tempting fix is "sticky sessions": configure the load balancer to always send a given user to the same server, using something like IP hashing. This works, technically, but it quietly reintroduces the exact problem statelessness was supposed to solve: if that one server crashes, every user pinned to it loses their session. It also makes load balancing uneven, since some servers can end up with disproportionately "sticky" heavy users.
The Real Fix: Push State Out of the Server
- -Shared session store: session data lives in a fast external store (usually Redis) that every server can read. Any server can serve any user, and losing one server loses nothing.
- -Tokens (e.g. JWTs): the session data itself is encoded into a signed token the client holds and sends with every request. No server-side lookup needed at all: the token is self-contained proof of who the user is.
This is the same "push state to external storage" idea you'll see again and again: it's exactly what makes the Cache module possible, and it's the same instinct behind moving long jobs to background Workers later in the course.
How do you keep a user logged in across multiple stateless servers?
"Store their session in the server's memory after they log in."
"That breaks the moment the load balancer sends their next request to a different server. Instead: either every server reads/writes session data from a shared store like Redis (sub-millisecond lookups, and any server can serve any user), or skip server-side storage entirely with a signed JWT the client holds, trading an external dependency for a harder-to-revoke token."
What is the main risk of "sticky sessions" (routing a user to the same server every time)?
Level 2: The 3-Tier Web App asks you to build exactly this shape - a load balancer in front of multiple stateless web servers, talking to a single database. Go build it, then come back for Databases 101.