Stateful and Stateless Components: Deciding Where Memory Lives

Every useful application remembers something: accounts, orders, messages, progress, preferences, or files.

The architectural question is not whether state exists.

A stateless component keeps no essential client history between operations; a stateful component retains information needed for later work. State always lives somewhere.

Moving state out of one server can make that server replaceable, but it also creates dependencies on the systems that now own the state.

A concrete example: login sessions

Suppose a web server stores session data in its own memory.

After login:

session abc -> customer 1042

The next request must reach the same server. If the server restarts, the session disappears.

Move session data to a shared store or use a signed self-contained token, and any web server can handle the next request.

The web tier becomes stateless with respect to the session. The shared store or token still carries state.

What state includes

State can be:

• Durable business records
• User sessions
• Workflow progress
• Files
• Cache entries
• In-memory counters
• Queue messages
• Locks
• Model parameters
• Configuration

Some state is authoritative. Some is derived and rebuildable.

Classifying it helps determine:

• Durability
• Backup
• Consistency
• Lifetime
• Ownership
• Replication

A cache entry and an accepted payment record should not receive the same guarantees.

Stateless request handlers

A stateless handler produces a response from:

• Current request
• Explicit configuration
• Shared external services

It does not depend on private memory from an earlier request.

Benefits include:

• Easy horizontal scaling
• Simple load balancing
• Safe replacement
• Easier rolling deployment
• Better fault recovery

Stateless does not mean no local memory.

A process may cache data or maintain connection pools as performance optimizations, as long as correctness does not depend on their survival.

Stateful components

A stateful component owns or retains information across operations.

Examples:

• Database
• Message broker
• Collaborative document session
• Game server
• Workflow engine
• Stateful stream processor

Stateful does not mean unscalable.

It means scaling requires decisions about partitioning, replication, coordination, and ownership.

Stateful systems often need stable identity so storage and peers know which instance owns which data.

Local state and affinity

Keeping state local can reduce latency and simplify one process.

Examples:

• Game simulation in one server's memory
• Video editing on one workstation
• Embedded database in a mobile app

The cost is affinity: later work must reach the same place or state must move.

Load balancers can use sticky sessions, but server failure still loses volatile state.

Affinity can be acceptable when the session is short-lived, recoverable, or deliberately assigned.

Durable and ephemeral state

Durable state must survive expected process and hardware failure.

Ephemeral state can be lost and reconstructed or abandoned.

Examples:

• Order record: durable
• Generated thumbnail cache: rebuildable
• Temporary upload chunk: perhaps ephemeral until commit
• In-progress bank transfer: durable workflow state

Labeling state ephemeral should be a business decision.

If users spend an hour editing a document, losing the "temporary" draft may be unacceptable.

Source of truth

When several copies exist, identify the authoritative one.

Copies may include:

• Primary database
• Read replica
• Cache
• Search index
• Analytics store
• Offline client

Ask:

• Which accepts writes?
• How do copies update?
• How stale may they be?
• How are conflicts resolved?
• Can a copy be rebuilt?

Without a source-of-truth rule, recovery and correction become ambiguous.

Sometimes authority is distributed, such as offline collaborative work, requiring explicit merge semantics.

Replication

Replication places state on several machines for:

• Availability
• Read scaling
• Geographic latency
• Disaster recovery

Synchronous replication waits for copies before confirming a write, improving consistency at a latency and availability cost.

Asynchronous replication confirms earlier but replicas may lag and lose recent writes during failure.

Replication duplicates both valid changes and mistakes. It does not replace historical backups.

The consistency guarantee must match user expectations.

Partitioning

Partitioning divides state among owners.

Examples:

• Customer ID hash
• Geographic region
• Time range
• Document ID

Each partition handles part of the data or workload.

Good partitioning balances load and keeps common operations local.

Challenges include:

• Hot partitions
• Cross-partition transactions
• Rebalancing
• Global queries
• Changing ownership safely

Partition design should follow access patterns and expected growth.

Concurrency

When several operations change shared state, races can occur.

Two buyers read one remaining item and both attempt purchase.

Protection can use:

• Database transaction
• Conditional update
• Lock
• Optimistic version check
• Single-owner event loop
• Queue serialization

The right mechanism depends on contention, latency, and correctness.

State ownership should make the invariant clear: who decides the final quantity?

State machines

A state machine defines allowed states and transitions.

An order may move:

pending -> paid -> shipped -> delivered
              \-> cancelled

Invalid transitions, such as shipping a cancelled order, are rejected.

State machines make workflow progress and recovery explicit.

Store enough information to distinguish:

• Not started
• In progress
• Succeeded
• Failed
• Compensated

A single Boolean often hides important intermediate states.

Idempotency and retries

Networks can time out after a state change succeeds.

The caller retries because it does not know the result.

An idempotency key lets the state owner recognize the repeated operation and return the original result rather than apply it twice.

This is essential for:

• Payments
• Order creation
• Message processing
• Provisioning

Retry safety is a property of the state transition, not merely the HTTP method name.

Caches are state with weaker authority

A cache contains state, but normally not the source of truth.

It introduces:

• Expiration
• Invalidation
• Eviction
• Cold starts
• Stale reads

A system should remain correct when cache entries disappear.

If important writes exist only in a cache, it has become an authoritative database whether the architecture calls it one or not.

Name the real guarantee.

Client-side state

Browsers and mobile apps store:

• UI selections
• Offline edits
• Drafts
• Tokens
• Cached content

Client state can improve responsiveness and offline behavior.

It is untrusted from the server's perspective because users or malware can modify it.

The server must validate authoritative business actions.

Synchronization requires versioning, conflict handling, and clear privacy controls.

Recovery

For each important state, define:

• Persistence mechanism
• Backup
• Replication
• Restore process
• Maximum data loss
• Maximum recovery time
• Reconciliation

After recovery from an earlier backup, external systems may contain later effects.

For example, a payment provider may show successful charges that the restored order database no longer contains.

Reconciliation compares systems and repairs missing state.

Knowledge check

1. What makes a request handler stateless?
2. Why does moving sessions to a shared store not remove state?
3. How do durable and ephemeral state differ?
4. What problem does idempotency solve after a timeout?
5. Why can restoring a database require reconciliation with external systems?

The one idea to remember

Stateless components are replaceable because essential history lives elsewhere. Architecture must still identify where state lives, who owns it, how concurrent changes remain correct, and how it is replicated, restored, and reconciled.