CQRS [pattern] v1.0.0

Command Query Responsibility Segregation. The model that handles writes (commands) is separated from the model(s) that handle reads (queries). The write model owns the invariants and emits events; one or more read models subscribe to those events and shape themselves for the queries the UI actually runs. The two sides scale, evolve, and are stored independently.

Label

CQRS — split the write model from the read model

Problem

A single normalized schema that serves both transactional writes (strict invariants, narrow tables) and rich read views (joins across many tables, denormalized, possibly across service boundaries) ends up bad at both. Reads get slow, writes get tangled, and the team can't refactor either side without affecting the other.

Solution

    Split into two sides connected by an event stream:

      Commands → Write Model → Event Store → Event Bus
                                                  ↓
                          Read Models (one per query shape)
                                  ↑
                            Queries (read-only)

      - Write side: small, normalized, enforces invariants.
      - Event store / bus: append-only event log of state changes.
      - Read side(s): denormalized, optimized per UI screen; rebuilt by replaying events.

    Reads are eventually consistent with writes; latency is small (milliseconds) but not zero.
  

CQRS [pattern] v1.0.0

Command Query Responsibility Segregation. The model that handles writes (commands) is separated from the model(s) that handle reads (queries). The write model owns the invariants and emits events; one or more read models subscribe to those events and shape themselves for the queries the UI actually runs. The two sides scale, evolve, and are stored independently.

Label

CQRS — split the write model from the read model

Problem

A single normalized schema that serves both transactional writes (strict invariants, narrow tables) and rich read views (joins across many tables, denormalized, possibly across service boundaries) ends up bad at both. Reads get slow, writes get tangled, and the team can't refactor either side without affecting the other.

Solution

    Split into two sides connected by an event stream:

      Commands → Write Model → Event Store → Event Bus
                                                  ↓
                          Read Models (one per query shape)
                                  ↑
                            Queries (read-only)

      - Write side: small, normalized, enforces invariants.
      - Event store / bus: append-only event log of state changes.
      - Read side(s): denormalized, optimized per UI screen; rebuilt by replaying events.

    Reads are eventually consistent with writes; latency is small (milliseconds) but not zero.
  

Relations

enhances: [@backend-architecture/pattern-database-per-service]

Label

CQRS — split the write model from the read model

Problem

A single normalized schema that serves both transactional writes (strict invariants, narrow tables) and rich read views (joins across many tables, denormalized, possibly across service boundaries) ends up bad at both. Reads get slow, writes get tangled, and the team can't refactor either side without affecting the other.

Solution

    Split into two sides connected by an event stream:

      Commands → Write Model → Event Store → Event Bus
                                                  ↓
                          Read Models (one per query shape)
                                  ↑
                            Queries (read-only)

      - Write side: small, normalized, enforces invariants.
      - Event store / bus: append-only event log of state changes.
      - Read side(s): denormalized, optimized per UI screen; rebuilt by replaying events.

    Reads are eventually consistent with writes; latency is small (milliseconds) but not zero.
  

Enhances

• @backend-architecture/pattern-database-per-service