Single State Model Architecture

Source: Dev.to

Problem Statement

Modern system architectures often prioritize 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, a user interface may 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.

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

In short, many modern architectures lose 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.

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 this model, all 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. Every application and component draws from the same well of truth for session‑specific information.

Key points

• A single source of truth for session state consolidates data that would otherwise be scattered across many services.
• 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.
• All other layers (caches, UI displays, logs) are merely reflections of that one state.
• By having one canonical state object per user session, the system ensures a consistent and up‑to‑date view of the user’s data regardless of which part of the application they interact with.

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), eliminating conflicting versions.
• State Unification: Disparate state is unified into a single logical model. User identity, preferences, roles, and other context share one state space.
• Simplicity Over Complexity: Designs favor straightforward, predictable behaviour over clever abstractions.
• Strong Consistency: Changes to the session state are immediately available to all parts of the system. The model prefers synchronous or atomic updates over eventual consistency.
• Transparency: Engineers and operators can point to one session record and comprehend the user’s current state.

Non‑Goals

• Unlimited Horizontal Scale: The model intentionally recentralizes session information and does not pursue a fully state‑partitioned design for arbitrary scaling.
• Polyglot or Per‑Service Data Models: It does not cater to each service having its own bespoke view of the user’s state; instead, it standardizes the session data model.
• Cutting‑edge for Hype’s Sake: Technologies like blockchain or exotic consensus algorithms are avoided; the aim is predictability, not trend‑following.
• Replacing Databases of Record: The single session state is not a long‑term system of record for all data (e.g., order history). It concerns active session state—ephemeral, changeable data needed during a user’s interaction.

Minimal Logical Architecture

Core Components

• 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 that 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 and 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

flowchart LR
    subgraph Client_Side [Client Side]
        user[User
(Browser/App)]
    end
    subgraph Server_Side [Server Side]
        gateway[Gateway]
        idp[Identity
Provider]
        session[Session
Store]
        subgraph Apps [Applications]
            app1[Application 1]
            app2[Application 2]
        end
    end

    user -- Login / Requests --> gateway
    gateway -- Verify Identity --> idp
    idp -- User Identity --> gateway
    gateway -- Read/Write Session --> session
    gateway -- Forward request --> app1
    gateway -- Forward request --> app2
    app1 -- (If needed) Read/Update --> session
    app2 -- (If needed) Read/Update --> session

Session Lifecycle Example

Lifecycle Sequence Diagram

sequenceDiagram
    participant User
    participant IdP as Identity Provider
    participant Gateway
    participant Session as Session Store
    participant AppA as Application A
    participant AppB as Application B

    User ->> IdP: Submit login credentials
    IdP -->> User: Return authentication token (if valid)
    User ->> Gateway: Open App A (with token)
    Gateway ->> IdP: Validate token/identity
    IdP -->> Gateway: Identity confirmed
    Gateway ->> Session: Create new session for user (store state)
    Session -->> Gateway: Session created (ID and data)
    Gateway ->> AppA: Forward request with user context
    AppA ->> Session: Update session data (e.g., user updates profile)
    Session -->> AppA: Confirm update
    AppA -->> Gateway: Send response for App A request
    Gateway -->> User: Response from App A (reflecting updated state)

    %% User accesses another application in the same session
    User ->> Gateway: Open App B (with token or session ID)
    Gateway ->> Session: Fetch current session state
    Session -->> Gateway: Return session data (including latest updates)
    Gateway ->> AppB: Forward request with user context
    AppB -->> Gateway: Send response for App B request
    Gateway -->> User: Response from App B (consistent with updated state)