Stateful vs stateless
Why stateless services are cheaper to scale — and where state has to live instead.
A stateless service holds no memory between requests — anything it needs, it fetches from a shared store. A stateful service keeps state in memory (session, cache, WebSocket connection). This distinction decides your entire scaling story.
Scaling comparison — N → N+1
- Spin up new VM
- Register with load balancer
- Instantly serving traffic
- Time: seconds
- Spin up new VM
- Migrate 1/4 of state from existing instances
- Rebalance routing (consistent hashing)
- Verify data replicated + consistent
- Time: minutes to hours
The interview soundbite
“Make the API tier stateless — sessions in Redis, uploads to S3, business logic on demand. State lives in the datastore, and only the datastore. This is the single most important decision for horizontal scaling.”
Where state has to live
Redis or DynamoDB — client sends session ID, backend fetches on demand.
Same as session — fetch on login, cache in-memory per request.
S3 with pre-signed URLs — browser uploads directly.
Can't avoid stateful WS servers. Use sticky routing (Slack team-affinity).
Redis atomic counters — shared across all API instances.
LaunchDarkly / Unleash — fetched once at startup, updated via SSE.
Applied in these systems
Practice what you just read
Every foundation concept has a companion quiz to close the loop.