Stateless vs Stateful Services Lab (Interactive)
Crash the hottest pod and count how many of 10,000 users lose sessions under sticky affinity vs externalized Redis state. Model traffic skew across pods, kill nodes, and compare session loss, orphaned capacity, Spot-instance eligibility, and Redis hop latency.
Sticky Sessions vs Stateless Fleet Survivability
Kill a node and see whether 10,000 users lose their sessions or just move on.
How It Works Under the Hood
Sticky sessions bind a client to one server because its HttpSession lives in that machine's RAM. Power-user skew then concentrates traffic on individual nodes, autoscaling new pods fails to offload them, and any crash or deployment rotation destroys pinned carts. Externalizing state to a sub-millisecond Redis cluster makes any pod able to serve any request, converting Spot terminations and rolling restarts into no-ops at the cost of one extra network hop per state lookup.
Core Architectural Principles
- Session affinity (cookie or IP hash) pins users, so a crashed node equals immediate session loss.
- Stateless pods can run on Spot capacity at 70-90% discount because they hold nothing worth saving.
- WebSockets stay stateful at the transport layer, so gateways scale via a Redis Pub/Sub backplane.
When asked to scale a stateful system, propose immediately: stateless edge gateway fleet, Redis session tier, and a Pub/Sub backplane for WebSocket fan-out. Contrast Kubernetes Deployments (interchangeable pods) with StatefulSets (kafka-0 ordinals, stable DNS, dedicated PVCs) to show you know which workloads may keep state.
Externalized state costs an extra ~0.5 ms hop per lookup but unlocks instant elasticity, zero-downtime deploys, and Spot economics; true engines like Kafka still belong on StatefulSets.