Managing State in Web Applications

State management: The discipline of deciding which facts live where, how long they remain authoritative, and which part of the system is allowed to change them.

State is where many web systems stop being simple. Not because Clojure makes state hard, but because HTTP, browsers, caches, sessions, and databases all tempt teams to store the same information in too many places at once.

The stronger design habit is to classify state before you implement it.

Start by Separating State Categories

Most web applications contain several very different kinds of state:

• request state such as path params, auth context, and correlation IDs
• client UI state such as open panels, draft form fields, or optimistic interactions
• identity or session state such as who the user is and what session is active
• cached derived state such as expensive lookups or rendered fragments
• durable domain state such as orders, invoices, and audit records

Those categories should not all be stored in the same place.

The visual below shows the healthier shape: a mostly stateless web layer backed by explicit external stores with different responsibilities.

Durable Business State Belongs Outside the Web Layer

The most important rule is simple: authoritative domain data should live in durable storage, not in cookies, not in local storage, and not in a process-local atom inside the web service.

That means:

• session data is not your system of record
• cache entries are not your system of record
• browser state is definitely not your system of record

If a fact must survive deploys, restarts, and multi-instance scaling, it belongs in the primary data store or another explicitly durable subsystem.

This sounds obvious, but many web failures come from violating it indirectly. Teams put authoritative workflow flags into Redis, recreate them from incomplete events, cache partially computed permissions, or let browser state drift into server truth. The bug is often architectural before it is technical.

Sessions and Identity Are Not the Same as Business Data

A session answers questions like:

• who is this user?
• when does this login expire?
• what identity claims have we already established?

That is different from storing mutable business objects in the session itself. Sessions are good for identity continuity. They are usually a bad place for large or authoritative domain aggregates.

Token-based approaches such as JWTs can reduce server-side session storage, but they do not remove the need for server-side authority. Roles, permissions, and revocation-sensitive decisions often still need a trusted backend check.

The key distinction is:

• a session tells you who the requester is and which identity context is active
• durable domain state tells you what the system believes about orders, invoices, approvals, or permissions right now

Those are related, but they should not collapse into the same storage model.

Cache State Should Be Treated as Derived

Caches improve latency and reduce load, but they do not define correctness. A cache is strongest when the team can answer two questions clearly:

• what is the source of truth?
• what invalidates this cache entry?

If those answers are vague, the cache often becomes the beginning of stale-data bugs.

In Clojure services, caches usually work best for:

• expensive read models
• repeated remote lookups
• computed views or fragments
• idempotent reference data with clear refresh rules

They are dangerous when used as an undocumented substitute for persistence.

The more a cache participates in correctness, the more it starts acting like a database without database discipline. If stale or missing cache data can create broken decisions, the team usually needs a clearer source of truth, invalidation contract, or read model.

Client State Should Stay Client-Shaped

Browser code often needs local state for forms, selection state, sort order, modal visibility, or optimistic pending changes. That is normal and healthy.

The mistake is assuming that because the browser currently holds a value, it is therefore the authoritative value. Client state exists to support the user interaction model. It does not replace server-side validation, server-side authorization, or durable persistence.

This is especially important in richer ClojureScript front ends. Shared language and shared validation helpers are useful, but the browser is still an untrusted runtime. Great UX can validate early and keep interactions fast without pretending the client is the authority.

Hidden Global State Is Still a Trap

Clojure makes explicit state containers such as atoms, refs, and agents easy to use. That is helpful, but in web systems it also creates a temptation to store process-local mutable state that quietly breaks under scaling or redeploys.

An atom can be fine for:

• metrics counters
• ephemeral caches with clear scope
• in-memory dev tooling

It is usually the wrong choice for:

• sessions in multi-instance production systems
• durable workflow state
• cross-request business ownership

Even when local mutable state is technically safe, it needs a lifecycle story. Ask:

• what resets it?
• what happens after deploy?
• what happens if the process crashes?
• what happens when traffic hits another node?

If those answers are fuzzy, the design is relying on accidental locality.

Use a Simple Decision Matrix

When placing a piece of state, classify it on three axes:

• authority: is it authoritative or derived?
• scope: is it request-local, browser-local, service-local, or shared across the fleet?
• lifetime: should it last milliseconds, minutes, a session, or forever?

That usually gives better answers than starting from tools such as Redis, cookies, or atoms.

For example:

• a correlation ID is request-local and short-lived
• a shopping-cart draft in the browser is client-local and interaction-oriented
• a login session is identity state with explicit expiry
• a cached catalog fragment is derived and replaceable
• an order record is authoritative and durable

Once those classifications are explicit, arguments about storage technology become much easier.

Practical Heuristics

When deciding where a piece of state should live, ask:

• does it need to survive restarts?
• does it need to be shared across instances?
• is it authoritative or merely derived?
• is it user-interface state or domain state?
• what invalidates it?

Those questions usually make the storage choice clearer than starting with a favorite tool such as Redis, local storage, or an atom.

Common Failure Modes

Putting Too Much Into Tokens or Sessions

Identity context belongs there. Mutable domain state usually does not.

Treating the Cache as If It Were the Database

If a stale cache entry can break correctness, the invalidation strategy is probably underdesigned.

Letting Process-Local State Leak Into Architecture

What works on one node with one REPL session often fails the moment the service scales horizontally.

Ready to Test Your Knowledge?