Back to roadmap
Module 2 · Scale, Latency, CapacityDay 01320 min

Stateless vs Stateful

Where state lives is the most important architectural choice.

← PreviousNext →
Day 013

Stateless vs Stateful

Client
client
LB
edge
App
service
App
service
Redis
cache
Signal path
Stateless app tier with externalized state
Client
client
flow
LB
edge
LB
edge
flow
App
service
LB
edge
flow
App
service
Memory hook

Stateless vs Stateful: where state lives is the most important architectural choice

Mental model

make the invisible limits visible

Design lens

S3 round-trip slower than local disk.

Recall anchors
BadGood

Why it matters

A stateless service holds no per-request memory between calls; any server can answer any request. State must live somewhere — usually a database, cache, or token. Stateless app tier + stateful data tier is the canonical web architecture.

Deep dive

Hidden state kills horizontal scaling. In-process caches, sticky sessions, file uploads on local disk, and locks all bind a request to a specific machine.

Externalize: sessions in Redis or signed JWTs, files in S3, locks in a distributed locker, caches in a shared layer.

Stateful services (databases, brokers) still exist; we accept them as bounded and run them carefully (replicas, snapshots, careful failover).

Demo / scenario

Existing API stores upload temp files on local disk.

  1. User uploads file → handler writes to /tmp.
  2. Subsequent request can land on a different instance — file missing.
  3. Fix: write to S3 with presigned URL or move to a shared blob store.
  4. Now any instance can complete the workflow.

Tradeoffs

  • S3 round-trip slower than local disk.
  • Multipart uploads simplify large files.
  • Cleanup policies move from cron to bucket lifecycle rules.

Diagram

Client
LB
App
App
Redis
DB
Stateless app tier with externalized state.

Mind map

Check yourself

Loading quiz…

Sources & further reading

← PreviousNext →