Stateless vs Stateful

Side by Side

Dimension	Stateless	Stateful
Routing	Any node, any request	Affinity or entity-partitioned
Node death	Invisible (reroute)	Disruption + recovery
Deploys	Instant replace	Drain/migrate first
Autoscaling	Trivial	Rebalancing-aware
Failure domain	One request	Sessions, rooms, connections
Typical tier	API, workers, BFF	WS gateways, game rooms, primaries

The Default Posture

 architecture rule: make everything stateless that CAN be;
 confine genuine state to dedicated, purpose-built tiers.

 [ clients ]
     │
 [ LB ] ──► STATELESS api nodes        (cattle: replace freely)
     │           │
     │      [ Redis / S3 / queues ]   (state, but managed services)
     │           │
 [ ws-gateway ] ──► STATEFUL rooms/connections  (deliberate island)

 the design question is never "stateless vs stateful" globally —
 it's WHERE each piece of state lives and what its owner owes you

Decision Procedure Per Piece of State

 for each candidate state, ask in order:

 1. Can it be derived/carried?          → tokens, signed params: stateless
 2. Can a store own it?                 → sessions→Redis: stateless compute
 3. Is it connection-bound?             → WS: stateful gateway tier
 4. Is it latency-critical hot loop?    → in-process w/ single-owner partition
 5. Must it survive node death?         → replicate/checkpoint (cost!)

 most teams discover at step 2 that their service
 didn't need to be stateful at all.

The Hybrid Reality

 one product, both modes, cleanly separated:

 RideShare:
 - REST API (stateless) — trips, payments, profiles
 - location stream (stateful per-trip owners) — live pings
 - handoff: trip created via stateless API → assigned to an
   owner node → clients subscribe through gateway routing
 
 boundaries between modes are CONTRACTS (who owns what,
 how ownership moves), and those contracts are what
 interview designs actually probe

Common Failure Modes

 ✗ session state in app memory "temporarily" → sticky LBs forever
 ✗ local disk writes before S3 integration lands → data loss on scale-down
 ✗ singleton cron inside web pods → duplicated jobs after autoscale
 ✗ in-memory cache treated as source of truth → ghost data post-restart
 
 each is state smuggling; each converts scaling problems
 into CORRECTNESS problems. audits beat hope.

Interview Framing

Design answers earn points by declaring the split: “API tier is stateless — sessions are JWTs; live tracking is stateful with one owner per trip; ownership transfers on driver reassignment.” That sentence structure — mode, mechanism, boundary — is the scored pattern across every system-design variant of this question.