Every useful system remembers things somewhere: accounts, orders, carts, files, conversations, model outputs, job progress, locks, and database rows.

The design question is not whether state exists. It always does. The question is where that state lives.

A stateless service does not keep required per-client state inside one specific app instance. Any healthy instance can handle the next request because the important state lives somewhere shared, such as a database or cache.

A stateful service remembers information that affects future requests. That state may live in the process, on disk, or in a storage system tightly tied to the service.

Neither option is always better.

Stateless services are easier to scale, restart, and replace. Stateful systems are useful when the system needs memory across time, such as a database, workflow, game room, or live connection.

Most production systems use both.

This chapter covers what counts as state and the trade-offs between stateful and stateless designs.

State is any information that must survive beyond one function call or one request.

That includes login sessions, shopping carts, checkout progress, uploaded files, WebSocket room membership, and game room data.

It also includes locks, leases, job progress, database transactions, AI conversation history, vector indexes, caches, and warmed-up model-serving data.

State can live in several places. Each place has a trade-off.

State on the client, such as a JWT, local draft, or cached feed, reduces server storage but can be lost, stale, or changed by the user.

State in application memory, like an in-memory session, game room, or WebSocket connection map, is fast but tied to one process unless you copy it elsewhere.

A shared cache such as Redis can hold session data, rate-limit counters, or presence information for fast shared access. The cost is that Redis now becomes something your app depends on.

A database stores important records like orders, accounts, and workflow state. It is safer than memory, but reads and writes are slower.

Object storage is safe and cheap for large data such as uploads, generated reports, or model files. It is not ideal for tiny updates that change very often.

An event log like a Kafka topic, audit stream, or change history lets systems replay past events, but it needs consumers and careful ordering rules.

The design question is not "state or no state?" It is where should state live, who owns it, and what happens when that owner fails?

In a stateless architecture, each request carries enough information for the server to process it, or the server can fetch what it needs from shared systems.

The app instance does not rely on memory from a previous request.

Both requests can go to different app instances because neither instance needs private session memory.

Common Stateless Patterns

Stateless services usually follow a few simple patterns: requests carry credentials, important state lives in shared systems, and writes are designed so retries do not create duplicates.

Token-Based Requests

The client sends a credential such as an access token on each request:

The server validates the token and processes the request.

If the token is a self-contained JWT, the server may validate it without looking up a session. If the token is random-looking, the server or gateway still needs to look it up.

JWTs are not automatically better. They can reduce lookups in some designs, but they make logout, stale user data, key rotation, and safe token storage more important.

Shared State

Application servers stay stateless by moving state into shared systems.

Sessions go into Redis, files go into object storage, and user data goes into a database.

Long-running jobs go into a queue or workflow engine, search data goes into a search index, and conversation history goes into a database or a dedicated memory store.

The app instance can be replaced at any time because it is not the only place that knows what is happening.

Retry-Safe APIs

Stateless services often pair well with operations that are safe to retry.

For example, a retry of this request should not create duplicate users:

This is especially important when clients, gateways, or queues retry after timeouts. Stateless request handling does not remove the need to protect writes from duplication.

Advantages of Stateless Services

Stateless services are easier to scale out because any instance can handle any request. Failover is simpler too: if one instance dies, traffic can move to another.

Deployments are safer because rolling restarts and automatic scaling do not put important local state at risk.

Load balancing is simpler because the load balancer does not need to keep one user pinned to one server. Recovery is cleaner because important state lives in systems built to store it.

Trade-offs of Stateless Services

The trade-offs come from moving state outward. Every request may need database, cache, token, or object-store access, so shared systems see more traffic.

Requests may also get larger because tokens, headers, and request bodies need to carry more information.

Personalization still needs storage somewhere, because user-specific behavior depends on state.

Long-lived bearer tokens have their own risks. If stolen, they can be dangerous, and fully self-contained tokens can be hard to revoke.

Shared state also becomes critical. A stateless app tier can still fail if the database, cache, or identity provider is unavailable.

Stateless application servers are a strong default for APIs, web backends, serverless functions, and worker fleets. They are not a substitute for good data design.

In a stateful architecture, a component remembers information that affects future interactions.

That state may live in a process, on disk, on other nodes, or in a database tied closely to the service. The main idea is simple: the component has memory across time.

Stateful does not mean poorly designed. Databases, caches, queues, stream processors, workflow engines, game servers, and WebSocket gateways are stateful by nature.

If the next request must return to Server A, the service is harder to scale and fail over. If Server A dies before saving the state, the user may lose work.

Common Stateful Patterns

Stateful designs differ mainly in two ways: how much state they keep, and how safely they keep it.

That is the difference between a quick local cache and a system that can survive a node failure without losing work.

Sticky Sessions

Sticky sessions route the same user to the same server.

This can work for small systems or low-risk state, but it creates friction.

A busy user or tenant can overload one instance. Removing an instance can disrupt active users. Rebalancing traffic becomes harder. If local session data is lost, users may need to log in again.

Sticky sessions are sometimes acceptable as a temporary design, but they should not be the first choice for highly available systems.

Shared Session Store

A better web-session design stores session data in a shared store such as Redis or a database.

The app tier becomes mostly stateless, while the session store owns the state.

This improves load balancing and failover, but it adds a dependency that must be monitored, scaled, backed up when needed, and protected from overload.

Stateful Workers and Workflow Engines

Some workflows need progress that survives restarts. Payment authorization and capture, order fulfillment, loan approval, data imports, and AI agent runs with tool calls all need to survive worker restarts and partial failures.

For these, state should usually live in a workflow system, database, or event log, not in one worker's memory.

Workers can still be stateless executors while the workflow engine is stateful.

Stateful Connections

WebSockets, multiplayer sessions, and collaborative editing often keep connection state.

The gateway has to remember which socket belongs to which user, which room or document the user joined, the last heartbeat, delivery confirmations, presence, and cursor position.

The connection gateway may be stateful, but important product state should still be stored elsewhere. A WebSocket connection is not a database.

Advantages of Stateful Systems

Stateful systems provide continuity. They preserve context across many interactions.

They can reduce repeated lookups by keeping frequently used context close to the work. This makes them a good fit for long-running interactions such as games, collaboration, workflows, and streaming sessions.

They also support coordination. Locks, leases, leader election, and transactions all need state. Some systems also run faster when hot state stays in memory.

Trade-offs of Stateful Systems

The cost of statefulness shows up in scaling, failover, and day-to-day operations. State may need to be split, copied, moved, or shared, which makes scaling harder.

Failover is harder too. A replacement node must recover or rebuild the state it inherits. Backups, replication, consistency, rebalancing, and recovery become central concerns.

Popular users, tenants, rooms, partitions, or keys can overload the node that owns that state and create hot spots.

Deployments need more care because restarting nodes can interrupt active sessions unless state is moved elsewhere or connections are drained safely.

Stateful architecture is not a flaw. It is a responsibility.

A system can be stateless at one layer and stateful at another.

This is how many mature systems are designed: replaceable compute around stateful data systems.

The stateless layer is easy to add, remove, and restart. The stateful layer stores the important data, ordering, coordination, and recovery information.

Authentication is where many stateful/stateless discussions get confusing.

Session-based authentication is usually stateful:

Token-based authentication can be stateless, but not always. A self-contained JWT can be checked without a session lookup.

A random-looking token requires a lookup. A JWT paired with a logout list, allowlist, or server-side session check is not fully stateless either.

Do not choose JWTs only because they sound scalable. A Redis-backed session store can handle very high traffic and gives cleaner logout.

JWTs are useful, but they require careful design around lifetime, audience, issuer, key rotation, and storage.

Stateless application servers are a good choice when you want to scale by adding more instances and want any instance to handle any request.

They also fit when requests are independent and the server can fetch required data from shared systems.

They fit when you deploy often and rolling restarts should not disrupt user state. They also fit serverless and container platforms where instances are created and destroyed often, or when you want simple load balancing without sticky routing.

Stateful components make sense when the system must preserve important facts. Databases, queues, logs, and object stores are designed for this.

They also fit long-running workflows such as checkout, payments, imports, and AI agent runs that need recoverable progress.

Low-delay local context is another good reason. Games, collaboration rooms, and interactive sessions may keep hot state in memory.

Coordination tools like locks, transactions, leases, and leader election all need state. User experience often depends on continuity too, because drafts, carts, sessions, and conversation history should survive reconnects.

The best architecture often looks like this:

Stateless services handle compute. Stateful systems own the important state.

A few rules tend to hold up well when designing a service.

Keep application instances replaceable, so a restart never loses important user or business state.

Store important state in systems built to keep it, such as databases, queues, logs, object stores, or workflow engines.

Avoid sticky sessions unless you have a clear reason, because they make scaling and failover harder.

Use shared session stores for web sessions that need logout or access removal, since stateless tokens are not always the safest choice.

Design for retries, so stateless request handlers still use retry-safe keys or safe write patterns.

Plan how state changes over time, because stateful systems need backup, restore, replication, rebalancing, and schema changes.

Separate live connection state from important product state. A WebSocket gateway may know who is connected, but the database should own messages, documents, and permissions.

The practical goal is not to make everything stateless. That is impossible.

The goal is to keep compute replaceable and put important state in the right place.

Every useful system has state somewhere, so the design question is where it lives.

A stateless service keeps no required per-client state inside any single instance. Any healthy instance can serve the next request because important state lives elsewhere.

A stateful service keeps state that affects future requests, either in the process or in a closely tied store.

Stateless services are easier to scale, restart, and fail over, which is why they are the common default for request handlers.

Stateful systems are unavoidable for data that must survive. They carry real operating work: backup, restore, copying data to other nodes, rebalancing, and schema changes.

Sticky sessions tie a client to one instance and make scaling and failover harder, so they need a clear reason.

Making everything stateless is impossible. The aim is to keep compute replaceable and put important state in the right place.

Store important state in systems built for it. Design request handlers so retries do not duplicate writes. Separate live connection state, such as which client a WebSocket gateway is holding, from the product state that a database should own.