- Stateless and stateful describe responsibility, not the entire system
- Why stateless compute is such a strong cloud default
- Stateless does not mean “store nothing”
- Session state is where the distinction becomes practical
- When stateful application components are justified
- State creates a failure problem, not just a storage problem
- Externalizing state also has a price
- The cost model changes with the placement of state
- A practical decision path
- Common mistakes when designing for statelessness
- Keeping hidden state on otherwise disposable instances
- Using sticky sessions as the default scaling mechanism
- Moving every piece of temporary data into a database
- Scaling compute while ignoring the state layer
- Building distributed state management before it is necessary
- Where managed services change the architecture
- The final architecture rule
- Continue exploring scalable cloud systems
Stateless architecture is often presented as the default for cloud-native applications: keep compute interchangeable, scale horizontally and replace failed instances without worrying about what they remember. That advice is useful, but incomplete. Most useful applications have state somewhere. The architectural question is not whether state exists, but where it lives, who owns it and what guarantees depend on it.
Stateless and stateful describe responsibility, not the entire system
A component is stateless when it does not need locally retained information from previous interactions to process the next request. A request can arrive at one healthy instance, the next request at another, and both can perform the required work using the request itself and external systems of record.
A stateful component retains information that matters to subsequent operations. That state may be user session data, an in-progress workflow, an application cache whose contents affect correctness, a durable data set or another piece of information that cannot simply disappear when the instance disappears.
This distinction matters because almost no production application is stateless from end to end. A stateless API may depend on a stateful database. A stateless web tier may read session data from a distributed store. A worker may be disposable while the queue feeding it retains durable state.
The useful goal is not to eliminate state. It is to keep state out of components that do not need to own it.
That changes the design question. Instead of asking whether the application should be stateless, ask which parts of the system must retain state and which parts should remain replaceable.
Why stateless compute is such a strong cloud default
Cloud infrastructure rewards replaceability. Instances, containers and application processes are easier to operate when any healthy replica can perform the same role.
Consider an API running behind a load balancer. If every request contains enough information to authenticate the caller and locate the required persistent data, the load balancer can route requests across available replicas without preserving affinity to a particular instance.
That creates several useful properties at once.
- Horizontal scaling is simpler. Capacity can be increased by adding equivalent replicas.
- Failure recovery is cleaner. Losing one replica does not also mean losing unique application state stored inside it.
- Deployments are safer. Instances can be replaced during rolling deployments without migrating local session state.
- Load balancing is less constrained. Requests do not normally need to return to the same application instance.
- Autoscaling becomes more practical. Removing a replica does not require preserving information that exists only on that replica.
These properties align well with cloud orchestration. Kubernetes, for example, explicitly treats Pods as relatively ephemeral resources rather than durable machines. Its documentation also distinguishes workloads that can use interchangeable Pods from applications that require stable identity or persistent storage.
Make horizontally scaled application compute stateless by default. Introduce state at that layer only when the workload requires a property that cannot reasonably be provided elsewhere.
Stateless does not mean “store nothing”
One of the most common design mistakes is interpreting stateless architecture as an application without stored information. In practice, stateless compute usually means moving durable or shared state behind a defined interface.
A typical web application might therefore have several layers with different responsibilities.
| Component | Typical role | Preferred state model |
|---|---|---|
| Load balancer | Distribute requests | Minimal application state |
| Web/API tier | Process requests | Usually stateless |
| Session store | Retain shared session information | Stateful |
| Database | System of record | Stateful |
| Object storage | Persistent files and objects | Stateful |
| Queue or event system | Retain work or events across processing | Stateful where durability is required |
The architecture has not removed state. It has concentrated state in components designed to manage it.
This separation is often more valuable than pursuing statelessness as an absolute principle. Compute can remain disposable while databases, storage systems and other persistence services provide the durability guarantees the application actually needs.
Session state is where the distinction becomes practical
User sessions illustrate the trade-off particularly well.
Suppose a web server keeps a user’s session only in local memory. The first request reaches instance A, which creates the session. If the next request reaches instance B, that instance does not have the same information.
One response is session affinity, often called sticky sessions: route subsequent requests from the client back to the same backend. Major cloud load-balancing platforms support forms of session affinity, but affinity changes the operating model. A particular instance now matters to that user’s traffic.
Another approach is to move session information into a shared data store. Application replicas can then remain interchangeable because each replica can retrieve the session independently.
A third approach is to encode appropriate session or identity information into client-presented tokens, subject to the application’s security, revocation and data-size requirements.
Sticky sessions can preserve local state without redesigning the application, but they trade some of the flexibility of interchangeable compute for routing affinity.
That does not make affinity inherently wrong. It makes it a constraint that should be chosen deliberately rather than treated as a free substitute for state management.
When stateful application components are justified
Stateless compute is a useful baseline, not a universal requirement. Some workloads fundamentally depend on identity, locality or durable data attached to a particular component.
Databases are the obvious example. A database cannot behave like a disposable HTTP worker if its local data is authoritative. Distributed databases may replicate and partition that state, but replication does not make the database stateless. It makes state management a distributed systems problem.
Other workloads can have similar requirements: clustered data systems, brokers with persistent logs, applications that depend on stable network identities, and workloads where moving large working sets between nodes would impose unacceptable recovery or performance costs.
Kubernetes reflects this distinction directly. Deployments are commonly used for workloads whose replicas are interchangeable, while StatefulSets provide stable identity and storage-oriented behavior for workloads that need it.
The important point is not that every database belongs in a StatefulSet. Managed databases often move that responsibility outside the application cluster entirely. The point is that infrastructure should reflect the semantics of the workload rather than forcing every workload into the same lifecycle model.
State creates a failure problem, not just a storage problem
The operational cost of state becomes clearest during failure.
If a stateless application replica disappears, the usual recovery action is straightforward: stop sending traffic to it and start or use another equivalent replica.
If a stateful component disappears, several additional questions may become relevant. Is its state available elsewhere? Was the latest write replicated? Can another node assume its identity? Does persistent storage need to be reattached? Can two replicas accidentally believe they are authoritative? What happens to requests while ownership changes?
Those questions lead to replication, consensus, failover procedures, recovery objectives, backup strategy and consistency decisions.
Before making a component stateful, define how its state survives the loss of that component. “The disk is persistent” is not a complete recovery architecture.
Persistent storage protects against some failure modes. Replication protects against others. Backups address another class of failures. None automatically substitutes for the others.
Externalizing state also has a price
Moving state out of the application tier improves replaceability, but it does not make the complexity disappear. It relocates it.
A request that previously read session information from local memory may now call a remote cache or database. That introduces network latency, another dependency and potentially another failure path.
A shared state service can also become a scaling bottleneck. Adding API replicas does little if all of them contend for an undersized database or session store.
This is why “make everything stateless” is an incomplete scaling strategy. The application tier may scale horizontally while the state layer becomes the limiting resource.
Externalizing state makes compute easier to scale; it does not make the state itself easier to scale.
Architecture reviews should therefore trace the scaling path beyond the stateless tier. If application capacity doubles, what happens to database connections, cache traffic, storage throughput, queue depth and downstream dependencies?
The cost model changes with the placement of state
Stateless compute tends to support more aggressive elasticity. If replicas contain no unique durable information, capacity can often be added and removed according to demand without a state-migration process.
Stateful infrastructure has a different economic profile. Capacity may need to include storage, replicas, backup retention, cross-zone or cross-region data movement, provisioned throughput and additional recovery capacity. Scaling may also require data redistribution rather than simply starting another worker.
But externalizing state is not automatically cheaper. A managed database, distributed cache or durable messaging service can cost more than local application storage in direct infrastructure terms. The architectural benefit comes from the guarantees and operational model those services provide.
The correct comparison therefore includes operational consequences, not just resource prices.
Compare the cost of managing state externally with the full cost of keeping it locally: constrained scaling, recovery complexity, deployment restrictions and engineering effort.
A practical decision path
For most cloud applications, the strongest starting point is a stateless application tier backed by explicit state services. This keeps the scaling unit simple: replicas process work, while systems designed for persistence own durable information.
From there, add complexity only when a concrete requirement demands it.
| Requirement | Reasonable starting approach | When to reconsider |
|---|---|---|
| Horizontally scaled HTTP/API service | Stateless replicas | When locality or long-lived state materially improves the workload |
| User sessions | Shared external state or suitable client-presented tokens | When affinity has a clear operational or performance advantage |
| Durable business data | Database or managed persistence service | When consistency, scale or locality requirements demand a different data architecture |
| Disposable background workers | Stateless workers with durable work outside the process | When processing depends on large local state or stable worker identity |
| Database or persistent distributed system | Explicit stateful architecture or managed service | When operational responsibility can be reduced through a managed alternative |
The threshold for stateful application compute should be higher than “it is convenient to keep this value in memory.” Local state should earn its place through a measurable requirement such as latency, data locality, workload semantics or an unavoidable identity constraint.
Common mistakes when designing for statelessness
Keeping hidden state on otherwise disposable instances
An application may be described as stateless while still writing important files to local disk, maintaining authoritative in-memory queues or depending on process-local session data. The architecture only reveals its true statefulness when an instance is replaced.
Using sticky sessions as the default scaling mechanism
Affinity can solve a legitimate routing requirement, but using it solely to preserve accidental local state can make scaling and recovery more dependent on individual instances.
Moving every piece of temporary data into a database
Externalizing state does not mean every transient value deserves durable storage. Some data can be reconstructed, cached or safely lost. Persistence requirements should follow business semantics.
Scaling compute while ignoring the state layer
A service may expand from ten replicas to one hundred while all replicas depend on the same constrained database. The diagram looks horizontally scalable; the system is not.
Building distributed state management before it is necessary
Running stateful distributed systems introduces failure modes that application teams must understand and operate. If a managed service can provide the required durability, availability and scaling characteristics at an acceptable cost, owning the distributed state layer may add little strategic value.
Where managed services change the architecture
Managed cloud services can move stateful operational responsibility across an important boundary.
An application team may keep its compute tier stateless while relying on managed databases, object storage, caches or messaging systems for persistence. State still exists, but replication, storage lifecycle, failover mechanisms or maintenance may be partly handled by the provider, depending on the service.
This is one reason managed services can be architectural tools rather than merely operational conveniences. They allow teams to concentrate state in systems whose primary purpose is to manage it.
The trade-off is greater dependency on the service’s interfaces, scaling model, failure behavior, pricing and portability constraints. Externalizing state to a managed service reduces one category of operational responsibility while creating an architectural dependency that should be evaluated explicitly.
The final architecture rule
The strongest default for a scalable cloud application is not “everything must be stateless.” It is more precise: keep compute replaceable wherever the workload permits it, and place state behind explicit boundaries where its durability, consistency and recovery requirements can be managed deliberately.
Start with interchangeable application replicas. Externalize durable and shared state. Identify the actual system of record. Then examine the state layer itself for scaling and resilience constraints.
Only make application components stateful when stable identity, locality, performance or workload semantics provide enough value to justify the additional lifecycle and recovery complexity.
Do not ask whether the application has state. Ask which component should own each piece of state, how that state survives failure and whether putting it there makes the rest of the system easier to scale.
Continue exploring scalable cloud systems
Follow the state boundary into infrastructure scaling, performance constraints and the economics of operating distributed systems.
Cloud strategy, architecture and infrastructure decisions explained without vendor noise.