Stateless Services

The Definition

 STATELESS: the service holds NO client-visible state between
 requests. any node can serve any request at any time.

 request carries everything needed:
   auth credentials (token)  — not a server-side session memory
   all parameters            — not "continue where you left off"
   
 durable state lives ELSEWHERE: database, cache, object store,
 queue — dedicated systems built for state's problems

What Statelessness Buys

Property	Mechanism
Horizontal scaling	Add nodes; LB routes anywhere; linear capacity
Fast deploys	Drain + replace nodes freely; no session migration
Crash resilience	Node dies → requests reroute; users never notice
Autoscaling	Scale on load without state-partition concerns
Simple rollbacks	Old/new versions coexist; no sticky compatibility

Each row is a distributed-systems problem deleted, not solved.

The Statelessness Checklist

 audit any service for these state smugglers:

 ✗ in-memory sessions          → Redis or signed tokens
 ✗ local disk writes           → object storage (S3)
 ✗ in-process caches of truth  → external cache (local = optimization only)
 ✗ singleton background jobs   → queue workers / leader-elected jobs
 ✗ sticky LB sessions          → fix root cause instead
 ✗ counters/rate state local   → shared store with atomic ops
 
 local caches and buffers are fine — as long as their loss
 is invisible to correctness. cache ≠ source of truth

Tokens Over Sessions

 classic stateful:  session store maps sid → user on servers
 stateless:         JWT/signed cookie CARRIES identity claims;
                    every node verifies signature locally
 
 trade-offs to acknowledge:
 + zero shared session store on hot path
 − revocation is hard (tokens live until expiry)
   mitigation: short-lived tokens + refresh, or denylist in Redis
 − token size rides every request
 
 neither wins absolutely; statelessness shifts rather than
 eliminates the problem — know which problem you're choosing

Stateless ≠ Dataless

 common confusion: "stateless" doesn't mean touching no data.
 it means no state OWNED BY THE COMPUTE TIER.

 app node reads/writes Postgres constantly — hugely stateFUL work —
 yet remains stateless ITSELF: kill it mid-request,
 start another, nothing is lost but the one in-flight call.
 
 disposable compute over durable stores is the whole pattern

When Statefulness Is Unavoidable

 WebSockets/game servers/voice: connection IS state.
 handle honestly:
 - sticky routing by necessity (LB session affinity)
 - graceful draining on deploy (finish, then close)
 - state replication for failover (game rooms etc.)
 - or push state down into a Durable-Object-style
   single-owner primitive (own lesson later)

Interview Framing

“Design the API tier” answers should say stateless explicitly and show the audit reflex: sessions→tokens, uploads→S3, jobs→queues. The senior flourish is the caveat paragraph — connections and singletons need honest treatment, not pretending statelessness covers everything.