Single State Model Architecture

Adam Cerny — Mon, 15 Dec 2025 20:58:25 +0000

1. Problem Statement

Modern system architectures often prioritise scale and flexibility at the cost of simplicity and consistency. In the rush to adopt microservices, event-driven patterns, and complex cloud tooling, many systems end up with fragmented state spread across services. Each service might have its own database or cache, leading to multiple sources of truth for the same information.

This fragmentation causes inconsistencies – for example, it's not uncommon for a user interface to show one value while a backend service or log shows another, simply because different parts of the system aren't in sync. Such divergence makes troubleshooting feel like solving a puzzle, because no single component knows “the whole story” of the system's state.

Furthermore, over-abstraction and hype-driven design can worsen the situation. Layers of middleware, countless APIs, and over-engineered frameworks often add complexity without clear benefit to the end user. Teams may adopt “stateless” token-based authentication or overly asynchronous communication in the name of modern best practices – only to find that nobody knows where a piece of data truly lives or which part of the system is authoritative.

The Result: A system that is technically sophisticated but hard to reason about and unpredictable in behaviour.

In short, what many modern architectures get wrong is losing sight of clarity and single-point accountability for state. Without a unified approach to managing state, systems become harder to maintain, and users encounter confusing or inconsistent experiences. There is a need to return to an architecture where simplicity, predictability, and a single source of truth for critical state data take centre stage.

2. Definition of the Single State Model

The Single State Model is an architectural approach that establishes one authoritative state for each user session across the entire system.

In a Single State Model architecture, all the data representing a user’s current session and context is maintained in one place (a single state store), rather than being duplicated or derived in each service. This means every application and component draws from the same well of truth for session-specific information.

Put simply, the Single State Model creates a single source of truth for session state – it is the practice of consolidating data that would otherwise be scattered across many services into a single location.

Instead of each microservice or frontend keeping its own copy of user context (leading to out-of-sync situations), the model insists that one central session state is the ground truth.
Everything else (caches, UI displays, logs) is merely a reflection of that one state.

By having one canonical state object per user session, the system ensures that no matter which part of the application a user interacts with, they see a consistent and up-to-date view of their data.

3. Design Principles and Non-Goals

Design Principles

Single Source of Truth: Every piece of session-specific data is stored and updated in one place (the central session store). This eliminates conflicting versions of data.
State Unification: The architecture unifies what would be disparate state into a single logical model. User identity, preferences, roles, and other context share one state space.
Simplicity Over Complexity: Designs favour straightforward, predictable behaviour over clever abstractions.
Strong Consistency: Changes to the session state are immediately available to all parts of the system. The model opts for synchronous or atomic updates to the single state over eventual consistency.
Transparency: It should be easy to understand the flow of data. Engineers and operators can point to one session record and comprehend the user's current state.

Non-Goals

Unlimited Horizontal Scale: The model intentionally recentralises session information. It does not pursue a fully state-partitioned design at the session level for the sake of arbitrary scaling.
Polyglot or Per-Service Data Models: This architecture does not cater to each service having its own bespoke view of the user’s state. It standardises the session data model.
Cutting-edge for Hype’s Sake: It consciously avoids technologies like blockchain or exotic consensus algorithms for session state. The aim is predictability, not adopting trends.
Replacing Databases of Record: The single session state is not a long-term system of record for all data (like order history). It concerns the active session state ephemeral, changeable data needed during a user’s interaction.

4. Minimal Logical Architecture

At a high level, the Single State Model architecture is composed of a few key components working in concert.

Identity Provider (IdP): An authentication service (e.g., SSO) that verifies credentials and issues identity tokens. It is the gatekeeper but does not handle session state.
Gateway: A unified entry point. It validates user identity and retrieves/updates the user’s session state from the store. It acts as both a traffic cop and a session facilitator.
Session Store: The heart of the model. A central repository (e.g., Redis, SQL) that holds each user’s session state as a single structured object.
Applications (Services): Backend services handling business logic. They are stateless with respect to user session. They rely on the gateway to supply context.
Client: The end-user’s interface (browser/app). Holds minimal state (usually just a token).

Component Architecture Diagram

5. Session Lifecycle Example

To understand how the Single State Model plays out in practice, consider a typical user session from login through using two different applications.

Lifecycle Sequence Diagram

Step 1: Login and Session Creation.
The user authenticates via the IdP. The Gateway validates the token and creates a session entry in the Session Store. This record is now the one source of truth.

Step 2: Using Application A.
The gateway forwards the request to App A with session context. If App A modifies state (e.g., updates profile), it writes back to the Session Store.

Step 3: Using Application B with Shared State.
The user navigates to App B. The Gateway fetches the current session data (including App A's changes) and forwards it. App B sees the profile exactly as App A left it.

6. Consistency Contract

The model defines a simple consistency contract:

One Authoritative State: All services agree that the session store’s version is the correct version.
Atomic Updates: Updates are all-or-nothing.
Read-Your-Writes Consistency: After an update, any component reading the state sees the new value immediately.
No Stale Reads: Because all reads go to the single source, the system avoids serving outdated info.
Graceful Handling of Conflicts: The contract guarantees no interleaving that could corrupt the session.
All-or-Nothing Session Validity: A session is either active and trusted, or it is not used at all.

7. Failure Modes and Graceful Degradation

No system is immune to failures, but the Single State Model is designed to fail gracefully.

Failure Component	Impact & Mitigation
Identity Provider	New logins fail gracefully. Existing sessions continue to work as the Gateway already has their state.
Session Store	Critical component. Mitigated by redundancy/clustering. If unreachable, the system degrades to a safe "read-only" or "maintenance" mode to prevent data corruption.
Gateway	If a node fails, load balancers switch to backup instances. If all fail, the system is unreachable (safe failure). Recovery is fast as the gateway is stateless.
Application Service	Failures are isolated. If App A fails, the user can still use App B. The session state remains intact and uncorrupted.
Network	Timeouts and retries handle glitches. If the store is unreachable, operations halt to prevent inconsistency.

8. Security and Access Control

Security is paramount since the single state contains the keys to a user’s experience.

Strong Authentication: Everything funnels through the Gateway with identity verification.
Session Isolation: Unique session IDs ensure users cannot access others' data.
Least Privilege: Services only access the parts of the session they need (scoped access).
Encryption: Data is encrypted in transit (TLS) and at rest in the Session Store.
Session Expiry/Revocation: Admin can kill a session in the central store, logging the user out universally and immediately.
Auditability: One session store means one audit trail for all user activity.
Minimal Attack Surface: Centralized auth logic reduces the chance of misconfiguration in individual microservices.

9. Why This Model Creates Calmer Systems

The overarching theme is calmness.

Predictability for Engineers: Fewer surprises. Debugging involves checking one state location rather than reconciling distributed logs.
Simpler Operations: Fewer moving parts mean fewer complex breakages. Recovery is methodical (fix the store, fix the gateway).
Better User Experience: Users experience consistent interactions. Data "travels with them" across the system without synchronization delays.
Reduced Cognitive Load: New developers grasp the "one system" pattern quickly. Product managers and users face less complexity.

By valuing simplicity and one reliable source of truth over trendy complexity, the Single State Model produces systems that are easier to build, reason about, and use.

DEV Community: Adam Cerny