Stateless Architecture

Keeping instances disposable by moving state somewhere shared, session management included

Disposablekill and replace, no data loss
State goes sharedDB, cache, object storage, queue
Sessionsshared store vs signed token
No local truthnever the sole source of record

1.Disposable application instances

A disposable instance can be killed and replaced at any moment without losing anything important — because nothing important lives only on that instance. This is what makes auto-scaling, rolling deploys and crash recovery all simple: killing an instance is a routine event, not an emergency.

Key features

Disposable: an instance can be killed and replaced at any time with no data loss
Requires: no data that only this instance has, and nothing that assumes this specific instance stays alive
Enables: auto-scaling (add/remove instances freely), rolling deploys, and automatic crash recovery
An instance crashing becomes a routine, self-healing event instead of an incident
The opposite — a "pet" instance that is hand-configured and irreplaceable — cannot be treated this way

Disposable vs "pet" instances

Disposable vs "pet" instances
Property	Disposable ("cattle")	Non-disposable ("pet")
Loses data on kill?	No — nothing important lives only there	Yes — has unique local state
Replaced by	An identical new instance, automatically	Manual recovery, often paged
Crash response	Auto-restart, no incident	Incident — this specific instance is gone
Enables	Auto-scaling, rolling deploys	Neither, safely

Disposable ("cattle") vs. "pet" instances

Disposable

No data lives only on this instance
Crash → auto-restart, no incident
Enables auto-scaling and rolling deploys

"Pet"

Has unique, hand-configured local state
Crash → paged, manual recovery
Cannot be freely killed and replaced

Command

text

disposable instance = no unique local state
                     + config/state from shared sources
                     + safe to kill and replace anytime

A disposable instance holds no unique state and can be killed and replaced at any time — the precondition for auto-scaling, rolling deploys and self-healing crash recovery.

2.Moving shared state out of the instance

To keep instances disposable, anything that needs to survive past a single request or be visible to every instance has to live somewhere shared: a database, a cache like Redis, object storage like S3, or a durable message queue — never only in one instance's memory or local disk.

Key features

Database: the durable source of truth for structured data (rows, documents)
Cache (Redis, Memcached): fast shared reads, often for session data or hot lookups
Object storage (S3-style): durable storage for files/blobs any instance can read or write
Durable messaging (a queue, Kafka): hands work between instances without relying on one instance's memory
None of these tie the data to any one specific application instance

Where state goes, by kind

Where state goes, by kind
Kind of state	Wrong place	Right place
User session	One instance's memory	Shared cache (Redis) or signed token
Uploaded file	One instance's local disk	Object storage (S3-style)
Work queued for later	One instance's in-memory list	A durable queue (SQS, Kafka, RabbitMQ)
Application data	One instance's memory/disk	A database

Both instances share the same session store

writeread

Instance A

writes the session

Redis

shared session store

Instance B

reads the same session

Command

text

shared state → database | cache | object storage | queue
                (never: this instance's memory or local disk)

Anything that needs to survive past one request or be visible to every instance goes in a database, cache, object storage or durable queue — never only in one instance's memory or local disk.

3.Session management in distributed deployments

With multiple stateless instances behind a load balancer, a user's session has to be readable by whichever instance handles their next request. Two dominant approaches: a shared session store (Redis, a database) every instance reads from, or a self-contained signed token (a JWT) the client holds, needing no shared store lookup at all.

Key features

Shared session store: server keeps session data in Redis/a database, client holds only an opaque session ID
Signed token (JWT): the session data itself lives in the token, cryptographically signed, held by the client
Shared store: needs a lookup per request, but sessions can be revoked instantly (delete the entry)
Signed token: no per-request lookup, but revoking one before its expiry is hard without an extra store anyway
Both approaches keep the application instance itself stateless — the difference is where the state lives

Shared store vs signed token

Shared store vs signed token
Property	Shared session store	Signed token (JWT)
Session data lives	Server-side store (Redis, DB)	Client-side, inside the token
Per-request cost	One lookup against the store	Verify a signature, no lookup
Instant revocation	Easy — delete the store entry	Hard — token is valid until it expires
Token size	Small (just an opaque ID)	Larger — carries the actual claims

Shared session store vs. signed token

Shared store

Client holds an opaque session ID
One lookup per request
Instant revocation — delete the entry

Signed token (JWT)

Session data lives in the token itself
No lookup — just verify the signature
Hard to revoke before its own expiry

Command

text

shared store: client holds opaque ID → server looks up data
signed token: client holds signed data  → server verifies, no lookup

A shared session store needs a per-request lookup but revokes instantly; a signed token skips the lookup but cannot be revoked before its own expiry without extra machinery — the application instance stays stateless either way.

Spotted a mistake on this page? Tell us.

Read Sheet