Stateless vs Stateful Architecture

State is information whose current value depends on earlier events: cart items, session identity, database rows, offsets, locks, and workflow progress. HTTP is stateless because one request does not inherently depend on a previous request, but cookies and application stores can link requests into a stateful session.

A stateless application instance does not depend on its own local memory or disk between requests. The request carries enough identity (for example, session cookie sid=cart-42) for any instance to retrieve required state from an external store. A stateful instance retains session or domain state locally and therefore has an identity that later work must find again.

The whole system is rarely stateless. “Make it stateless” normally means make compute replaceable and move durable/shared state behind an explicit contract. That improves routing and replacement while adding network calls and a shared dependency.

In the stateless version, the browser sends a secure session identifier with POST /cart/items. The load balancer chooses any healthy API replica. That replica validates the session, reads cart-42 from Redis or a database, applies the update atomically, and returns the new cart. No replica needs the previous request in local memory.

This design makes horizontal scaling and rolling replacement straightforward: add replicas and the load balancer gets more interchangeable targets; remove one and no session disappears with it. The trade is one or more remote state calls per request. Latency, connection pools, cache consistency, and shared-store availability now sit on the request path.

Do not put sensitive mutable cart state directly in an unsigned client payload. A cookie should usually contain an opaque session ID (with Secure, HttpOnly, and appropriate SameSite) or a signed token whose trust and revocation limitations are understood. The server still authorizes every cart operation.

In the stateful version, API instance A keeps cart-42 in process memory. The next request must return to A, commonly through load-balancer session affinity (sticky sessions). This can reduce remote reads and ease migration of legacy applications, but A is no longer interchangeable with B.

If A fails, its memory disappears and the sticky mapping cannot help. Uneven session sizes can also create hotspots: one instance accumulates heavy users while another sits idle. Scaling down requires draining sessions or accepting loss. Replicating local state between instances can repair some of this, but now you are building a distributed state store inside the application tier.

Some workloads are legitimately stateful: databases, consensus members, stream processors with local checkpoints, and game servers with active matches may need stable identity and storage. In Kubernetes, StatefulSets provide stable network identity, ordinal names, and persistent volume association; they do not make the application's replication or failover semantics correct automatically.

Compare the same second request after the user added a keyboard. With sticky local state, the load balancer reads its affinity cookie and routes to instance A; A reads its own memory and returns the cart. With external state, the load balancer may choose A, B, or C; the chosen replica reads cart-42 from the shared store.

The stateless path has an extra network dependency but a simpler compute failure boundary. The stateful path may be faster for a local read but needs affinity, draining, and a recovery story for A. “Faster” is therefore workload-dependent: measure remote-store latency against the cost of lost sessions, imbalance, and operational constraints.

Both designs still need concurrency control. Two tabs can add items at once. A local Map is safe only inside one process and still needs logic for conflicting updates; a shared store needs atomic commands, transactions, or compare-and-swap. State placement does not remove state semantics.

Trigger. cart-42 is stored only in instance A's memory. A rolling deployment terminates A before sessions drain. Symptom: the next request reaches B, which returns an empty cart; infrastructure dashboards look healthy because B responds 200. Root mechanism: session affinity routed requests but never replicated state, so the routing target was also the only data owner.

Recovery. Stop the rollout, keep the old instance pool alive where possible, and communicate that affected carts may need rebuilding. Do not pretend an empty cart is a successful recovery. Prevention: externalize cart state to a durable/shared store, or replicate/checkpoint it with an explicit loss window. During migration, drain sticky sessions before termination and instrument “session not found” as an error rather than a normal empty state.

The opposite failure matters too: externalizing sessions to Redis makes all replicas dependent on Redis. If it fails, blindly retrying can create a storm. Use bounded timeouts, circuit breaking, and a product decision: return 503, serve a signed read-only snapshot, or allow anonymous browsing without cart mutation.

Stateless compute scales by adding interchangeable replicas, but the state store must scale with it. Watch store latency, hot keys, memory, connection count, eviction, replication lag, and durability policy. A single shared Redis with no failover simply moves the single point of failure.

Stateful workloads scale by partitioning ownership: shard users, rooms, or keys across stable workers, then route work to the owner. Rebalancing moves state and can pause or duplicate work; consistent hashing reduces movement but does not solve replication, ordering, or recovery. This is why scaling a database is not equivalent to adding web replicas.

Security also follows the owner. Local sessions vanish on restart but may expose secrets in process dumps. Shared stores centralize sensitive state and require encryption, network isolation, least privilege, TTLs, and audit. Client-carried tokens reduce server lookups but make revocation and claim freshness explicit trade-offs; never put mutable authoritative cart contents in a token just to call the server “stateless.”

Prefer stateless application replicas for request/response APIs when any instance can reconstruct context from the request plus an external store. This is the default for horizontally scaled web tiers because replacement, rollout, and load balancing stay simple.

Use stateful workers when stable identity or local ownership is fundamental: databases, consensus nodes, ordered stream partitions, active game rooms, or large local working sets that cannot be reloaded per request. Then design placement, persistence, replication, failover, and rebalancing as first-class behavior.

Sticky sessions are a compatibility tool, not a durability mechanism. Use them temporarily for legacy local sessions or deliberately for locality, with draining and loss behavior documented. The decision rule is: place state where its consistency and recovery contract can be enforced, then make every other component replaceable.