1st Principles
Menu

Systems · 30 min read

State and Persistence

Why servers must remember things across requests, how memory and disk trade latency for durability, and how that general problem sits under web sessions and API resources.

Why this exists

HTTP requests and many RPC calls arrive as separate events. Users still expect login continuity, balances that survive restarts, and carts that do not vanish when a process dies.

State is remembered information. Persistence is state that survives process death and often machine reboot. Client-server systems usually keep authoritative state on the server side.

Cookies and sessions show one web mechanism for carrying a key to server memory. APIs and contracts describe how callers create and update resources. This lesson names the deeper storage problem those pages sit on.

Axioms & primitives

  1. 01Stateless request handling still needs somewhere to put durable facts if the product remembers anything.
  2. 02Authoritative state usually lives on the server side in client-server designs; clients hold caches and drafts.
  3. 03In-memory state is fast and fragile: process crash or restart forgets it unless rebuilt.
  4. 04Durable storage (disk, object stores, databases) survives process death at the cost of latency and operational complexity.
  5. 05A session token or resource id is often a pointer to state, not the full state itself.
  6. 06Consistency, durability, and latency trade off; pretending you can maximize all three without cost hides failure modes.

Learning objectives

After this lesson you should be able to:

  • Explain why a purely process-local memory map is not enough for "logged-in user" across rolling deploys.
  • Contrast in-memory state with durable storage using latency and survival-after-crash as criteria.
  • Explain how a session cookie relates to a server-side state pointer, and how a REST resource id relates to stored authoritative data.
  • Give one example where caching improves reads but must not become the only copy of money-like state.
  • Describe what "authoritative state" means when a client and server disagree after an offline edit.

Progressive depth

Read the layers in order for a full explanation. Or open the layer you need.

01

Intuition

A client opens a connection, asks for something, and may disconnect. The next request might come from another connection, another device, or another app process behind a load balancer. If "who is logged in" lived only in one process's RAM, rolling restarts and multi-instance servers would log everyone out or disagree.

So servers remember. Sometimes they remember for milliseconds in memory (rate-limit counters, hot caches). Sometimes they remember for years on durable storage (accounts, documents, payments).

Cookies and sessions solve a web-shaped slice of this: the browser holds a token; the server holds the session record the token names. REST-style APIs solve another slice: resources with ids that refer to stored representations. Both assume a persistence story underneath.

The central tradeoff is blunt. Memory is near the CPU and dies with the process. Disk and remote databases survive and cost round trips. Caching sits in between: copies that may be stale on purpose.

02

Formal shape

Classify state by lifetime and authority. Request-scoped: exists for one handler invocation. Session-scoped: tied to a login or anonymous cart lifetime. Durable domain state: survives sessions (orders, documents, user profiles).

In-memory stores (process heaps, local caches, many Redis-as-cache setups) optimize latency. Without replication and explicit durability settings, assume crash loss. Durable systems (databases, write-ahead logs, object storage) fsync or equivalent policies decide what "committed" means after power loss.

Pointers versus payloads: opaque session ids and resource ids are references. The contract (APIs and contracts) says what operations on those ids mean. Authorization decides who may read or mutate the pointed-to state.

Consistency choices: strong read-after-write on a primary; eventual copies on replicas and CDNs; optimistic concurrency with versions or ETags when two writers meet. Concurrency control (locks, transactions, single-writer queues) is how overlapping updates keep the ledger honest.

Deployment reality: "stateless app servers" usually means app processes can be killed and replaced because authoritative state is externalized. It does not mean the system is memoryless.

03

Worked examples

Example A: login. Credentials authenticated; server inserts a session row (or record) with expiry; Set-Cookie carries the session id. Later requests load state by id. Restarting one app process is fine if the session store is shared and durable enough for your threat model.

Example B: in-memory only sessions on a single node. Fast. A deploy that restarts the node logs users out. Two nodes without sticky sessions disagree about who is logged in. The persistence choice leaked into product behavior.

Example C: create order via API. POST returns {id}. The id names durable state. A client retry without idempotency may create two orders. Contract and storage design meet.

Example D: cache the public product catalog at a CDN. Great for reads. Checkout inventory still needs authoritative stock counts in a database. Cache is not the ledger.

Example E: offline mobile draft. Client holds local state, then syncs. Conflict rules decide whether server or client wins. Authoritative policy must be explicit.

04

Edge cases

Soft state and TTLs: DNS answers and cache entries are supposed to expire. Treating them as forever durable facts causes stale outages.

Secrets in state: session contents and tokens need protection at rest and in transit. Persistence widens the blast radius of a disk theft or backup leak.

Partial writes: a crash between two related updates can leave orphans unless you use transactions or careful recovery.

Multi-region: durable in one region is not the same as durable everywhere. Failover can expose stale replicas if you promised stronger semantics.

"Just use a blockchain" or "just use a spreadsheet" slogans skip the latency, authz, and operational questions. Pick storage that matches the authority and lifetime you need.

GDPR-style deletion: persistence creates a duty to erase. Design delete paths when you design write paths.

Mental models

  • Coat check

    The ticket (cookie or id) is small. The coat (session data or resource) stays behind the counter (server storage). Losing the ticket and losing the coat room are different failures.

  • Whiteboard vs filing cabinet

    Memory is a whiteboard: fast, erased by a cleaner (restart). Disk is a filing cabinet: slower, still there tomorrow.

  • Bank ledger

    Balances need an authoritative ledger. Printed receipts and phone caches help humans but must not silently override the ledger.

  • Library card catalog

    APIs expose catalog numbers and operations. The books (bytes) live on shelves (storage). A contract without shelves is theater.

Common misconceptions

  • Myth

    If every request includes all needed data, the server is fully stateless and needs no storage.

    Reality

    The product still needs a source of truth for accounts, permissions, and history. Stateless app processes usually mean "state lives in a database," not "state does not exist."

  • Myth

    Putting state in a cookie means you do not need a database.

    Reality

    Cookies can hold small tokens or signed blobs. Size, revocation, and secrecy limits push important state server-side. See cookies and sessions.

  • Myth

    Memory and disk are interchangeable performance knobs.

    Reality

    They differ in durability and failure behavior. A restart turns pure memory into empty memory.

  • Myth

    Replication means you no longer think about persistence.

    Reality

    Replicas copy state among machines. You still choose what is durable, what can be stale, and what happens on split views.

Exercises

Work these without looking up answers first. Check yourself against the intent notes.

  1. Exercise 01

    A team stores sessions in process memory on each of three load-balanced app servers with no shared store and no stickiness. What do users experience, and what persistence change fixes the class of bug?

    Hint: Ask where the session record lives when the next request lands on another machine.

    What good looks like

    Random logouts or inconsistent auth depending on which instance they hit; shared session store (or sticky sessions as a weaker mitigation) externalizes state.

  2. Exercise 02

    Classify each as mostly memory-speed state or durable authority for a bank app: (a) per-request tracing id, (b) account balance, (c) CDN-cached marketing banner, (d) refresh token family for revoke.

    Hint: Ask what must remain true after every process restarts.

    What good looks like

    a ephemeral; b durable authority; c cache/soft; d durable (revocation must survive restarts).

  3. Exercise 03

    How does a session cookie relate to server persistence, and how does that differ from storing the entire user profile inside the cookie?

    Hint: Coat check ticket versus carrying the coat in your pocket.

    What good looks like

    Cookie as pointer to server-side session vs client-held payload; size, revoke, and secrecy tradeoffs; ties to cookies and sessions page.

Sources & further reading

External references. Prefer primary documents and clear explainers.

Go deeper on your own

These picks go past the foundation in this lesson. Use them when you want a primary spec, official docs, or a longer walkthrough.