The ideas behind
every system you'll design.

Model	Guarantee	Cost	Typical use
Linearizable	Reads see the most recent write, globally ordered	Highest latency, needs consensus	Locks, leader election, balances
Causal	Operations that depend on each other are seen in order	Moderate	Comments, messaging threads
Read-your-writes	You always see your own latest change	Low (session pinning)	Profile edits, settings
Eventual	Replicas converge if writes stop	Lowest latency, can read stale	Caches, view counts, DNS

Isolation level	Prevents	Still allows
Read Uncommitted	—	Dirty reads
Read Committed	Dirty reads	Non-repeatable reads
Repeatable Read	Non-repeatable reads	Phantoms (in classic SQL)
Serializable	Everything — behaves as if serial	Nothing (highest cost)

The second instance that breaks everything

Before. One application process, sessions held by the default in-memory store. A user logs in, the process writes sessions["abc123"] = {userId: 42, cart: […]} and sets a cookie. Every later request arrives with that cookie, finds the entry, and works. Traffic doubles, so you put a second instance behind the load balancer and change nothing else. The login lands on instance A and writes the session into A's heap. The next request round-robins to B. B looks up abc123, finds nothing, and treats the visitor as anonymous — a redirect to the login page, or a bare 401 from the API. The user signs in again, lands on A, works for a click or two, hits B, and is logged out again.

Half of everything now fails, non-deterministically, and only under the load you added capacity to survive. The same silent breakage hits everything else quietly parked in memory: CSRF tokens minted on A and rejected by B, multi-step wizards that lose step two, in-process rate-limit counters that suddenly allow twice the intended budget because each instance only counts its own half of the traffic, and a warm local cache whose hit rate collapses the moment a cold instance joins.

After. The session moves to Redis. The cookie still carries only abc123; both instances read and write the same key, under a TTL that expires it. Nothing on the request path is local any more. A can serve the login and B can serve the next click, and neither knows or cares. A rolling deploy can kill A mid-session, an autoscaler can add a fifth instance during a spike and remove it at 3am, and a crashed process costs exactly the requests it was holding — not the sessions of everyone who happened to be pinned to it. The bill is one network round trip, sub-millisecond inside an availability zone, plus a new dependency that now has to be at least as available as the service in front of it. That is the honest trade: a small, predictable latency cost in exchange for instances that are disposable.

The sticky-session trap

There is a cheaper-looking fix. Tell the load balancer to pin each client to one backend — by hashing the source IP (nginx ip_hash) or by issuing its own cookie (ALB sticky sessions). No application code changes, the logouts stop, and it reads like a solution. It is not: it is the original coupling relocated into infrastructure, where it is harder to see and harder to test.

Deploys break first. A rolling restart replaces instances one at a time, and every user pinned to a replaced instance loses their session — so routine deploys start logging people out, and the team learns to ship at midnight rather than fix the cause. Scale-out breaks second. New instances only receive new sessions, so adding capacity during a spike does almost nothing for the users already pinned to a saturated box; the fleet stays lopsided for as long as sessions live, and the dashboard shows idle instances next to one that is on fire. Scale-in breaks third. Terminating an instance is no longer free, so the autoscaler either refuses to shrink or drops live sessions when it does. Graceful draining, canary releases, and shifting traffic between availability zones all inherit the same defect. Keep stickiness if you want it for cache locality — never for correctness. If the system stops working when stickiness is switched off, the state is still in the wrong place.

Where state is supposed to live

Statelessness is not the absence of state — it is a deliberate decision about which systems are allowed to hold it. The application tier is not one of them; the systems below are built for it, and each answers a different question.

Home	What belongs there	Why there
Relational database	Data of record — users, orders, balances	Durable, transactional, queryable; the only correct home for a business fact
Redis / Memcached	Sessions, rate-limit counters, short-lived locks, hot lookups	Shared and fast, with TTLs that expire state for you — see caching patterns
Object storage	Uploads, exports, generated media	Cheap and effectively unbounded; never one instance's local disk
The token itself	Identity and coarse-grained claims	No lookup at all — the cost is bytes per request and awkward revocation (OAuth & auth)
Queue or log	In-flight work	A crashed worker's job is redelivered instead of lost (backpressure lab)

When stateful is the right answer

Plenty of services are stateful because the problem is. A WebSocket gateway holds a real TCP connection, and that connection is state living on exactly one machine — you cannot make it stateless, only recoverable. The working pattern splits the two apart: the socket stays pinned, the meaning does not. A shared pub/sub layer fans messages out to whichever gateway currently holds the socket, and clients reconnect and resume from a sequence number, so losing a gateway costs a reconnect rather than a conversation.

Realtime game servers and collaborative editors run an authoritative simulation in memory at thirty to sixty ticks a second; a network round trip per tick is not physically available to them, so they snapshot and journal instead. Stream processors such as Flink and Kafka Streams keep local state deliberately: a windowed aggregation lives in an embedded store on the instance that owns that partition, and correctness comes from the partition-to-instance assignment plus periodic checkpoints, not from having no state at all. Databases are the original case of the same idea.

What separates these from the accidental kind is that the state was declared. Someone chose it, wrote down how it is recovered, and sized the blast radius of losing one node. An in-memory session map has none of that — no checkpoint, no reassignment, no owner — just an assumption made once for one machine that quietly stops being true the day a second one appears. The rule the industry converged on, and the one the twelve-factor guidance states outright, is simply that: keep the application tier stateless and disposable, and let only the systems designed to hold state hold it.