Stateful Services

The Definition

 STATEFUL: the service's behavior depends on data held in the
 process (or pinned to it) across requests.

 examples:
 - WebSocket/chat server: open connections live IN the node
 - game/room server: match state lives with the room
 - leader-elected scheduler: "who runs" is cluster state
 - local-database embedded node: SQLite per instance

Why State Resists Scaling

 state binds requests to nodes:

 client ──► conn on app-2 ONLY
            (reconnect to app-3 = lost session, resubscribe, replay)

 consequences:
 - can't route any request anywhere → LB restricted to affinity
 - node death loses state → clients disrupted, recovery needed
 - deploy = drain conversations gracefully, slowly
 - autoscaling awkward: shrinking drops LIVE sessions
 
 every horizontal-scaling benefit has a state-shaped asterisk

Strategy 1: Push State Out Anyway

 first question: does the state NEED to be in-process?

 chat presence:  → Redis set of online users; servers stay stateless
 rate counters:  → Redis INCR
 shopping cart:  → database/cache keyed by session
 game position:  → maybe... or maybe not latency-tolerable

 most "stateful" services are accidentally stateful.
 genuine cases: long-lived connections, low-latency loops,
 write-heavy working sets too hot for external stores

Strategy 2: Partition by Entity (Single Owner)

 assign each entity to exactly ONE owner node:

 rooms:    hash(room_id) → server_i owns that room entirely
 devices:  gateway shard by device id
 objects:  Durable-Object model — one actor per entity

 [ router ] ──► owner(trip_1) ── holds trip_1 state
            ──► owner(trip_2) ── holds trip_2 state

 scaling = add owners + rebalance partitions.
 each entity still has ONE home → no distributed coordination
 within an entity. this is how real-time platforms scale.

Strategy 3: Replicate State for Survival

 when node death must be invisible:
 - replicate session/room state to standby peers
 - consensus groups (Raft) for critical small state
 - checkpoint to external store periodically;
   new owner restores from checkpoint on takeover

 cost: replication lag, write amplification, complexity.
 apply only where disruption is unacceptable

Operational Realities

Concern	Stateless answer	Stateful answer
Deploy	Replace pods instantly	Drain connections, migrate rooms
Failure	Reroute	Failover + state restore
Scale down	Kill extras	Rebalance entities off first
Monitoring	CPU/RPS	Lag, entity counts, drain progress

Stateful fleets need rebalancing machinery: moving live entities between nodes without dropping them is the core operational skill.

Interview Framing

Real-time designs (“live location tracking,” “multiplayer”) test stateful handling. Scored shape: identify the genuinely in-process state, try pushing it out, then partition-by-entity with single ownership per trip/room, plus explicit drain/failover stories. Saying “WebSockets make this stateless” fails; saying “one owner per entity, hash-routed” passes.