Statelessness

The problem

If a user's session lives in one server's memory, you can never safely add a second server.

The idea

Keep app servers stateless — they hold no per-user data between requests. Any server can handle any request.

How it works

State moves out: session data into a shared cache/DB, or into a signed token (JWT) the client carries. Either way the load balancer routes any request to any node. Sticky sessions (pin a user to one node) look easier but reintroduce the failure — that node dies and the session dies with it, and balancing skews.

The tradeoff

You trade an in-memory read for an external lookup (~1ms cache hit) to gain effortless scaling, zero-downtime deploys, and resilience. A self-contained token skips even that lookup but can't be revoked before expiry without a denylist — so you trade instant logout for statelessness, which is why access tokens are kept short-lived.

In the wild

JWTs and Redis-backed sessions exist precisely to make app servers stateless.

Interview deep dive

Flow

1. Move session state into a shared store or a signed token.
2. Validate the token/session on each request at the edge or app.
3. Let the load balancer route any request to any node.
4. Add/kill nodes and deploy without draining sessions.

Watch for

• Sticky sessions break on node death and skew balancing.
• JWTs can't be revoked early without a denylist — keep them short.
• A "stateless" app still depends on a stateful cache/DB underneath.

Interviewer trap

Name where the state went — a stateless tier just pushes state to a shared store.

Related Academy