Topic 9.3
Stateless Services
In one line
The principle that makes horizontal scaling, rolling deploys, and instance-juggling boring.
Think of it like this
A food stall where every order slip has ALL the details written on it (name, order, payment status). Any chef can pick up any slip and complete it, because nothing important is remembered 'in the chef's head' — it's all on the slip.
Key ideas
- 01
Stateless = no request-scoped state kept on the node between requests; all durable state elsewhere.
- 02
Where state goes: DB (persistent), Redis (fast shared state), Kafka (events), object store (blobs).
- 03
Consequences: kill any node anytime; scale up/down freely; rolling deploys without drain pain.
- 04
Local caches still help (each node caches) — but they're shared-nothing; the cache is a performance roof, not source of truth.
- 05
Anti-patterns: in-memory session, sticky sessions required, instance-pinned websockets (see 6.5).
- 06
Interview: 'statelessness is what makes this fleet boring — and boring is the goal.'
Explain without notes
A chat WebSocket server is stateful per connection — how do you keep scaling it horizontally?
Practice
Redesign 'user must land on same instance' flows (uploads, chat, cart) to stateless + shared store.
Trade-offs
- ↔
Moving state outward costs latency to Redis/DB but buys elasticity; the trade is usually a slam dunk.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can find instance-pinned state in any design and relocate it.