Event Sourcing and CQRS
Event sourcing stores state as an append-only log of immutable events rather than as mutable rows; current state is a fold over that log. CQRS (Command Query Responsibility Segregation) splits the write model from one or more read models. They are independent but pair naturally: the event log is the write side, and read models are projections built from it.
In a CRUD system you overwrite a row and lose history. In event sourcing you append MoneyDeposited, MoneyWithdrawn, … and never mutate; the balance is computed by replaying events. The log becomes the system of record, giving you a perfect audit trail, time-travel (reconstruct state as of any point), and the ability to derive new read models retroactively by replaying. Source: compiled from event-sourcing literature
How the pieces fit
- Command — an intent to change state; validated by an aggregate against current (replayed) state.
- Event — the immutable fact that results; appended to the log. Past tense, never deleted.
- Projection — a consumer that folds events into a query-optimized read model (a denormalized table, a search index, a cache).
- Query — reads hit projections, never the log directly.
CQRS
Separating commands from queries lets each side scale and model independently: the write side optimizes for invariants and consistency, the read side for query shape and speed (often eventually consistent, rebuilt from events). The cost is complexity — two models to keep in sync — so apply CQRS where read and write loads genuinely diverge, not everywhere. Source: compiled from CQRS literature
Design implications
- Eventual consistency by default. Projections lag the log; the read model is "soon," not "now." Design UX for it (or read-your-writes where required).
- Snapshots bound replay. Replaying millions of events per load is slow; periodic snapshots cap reconstruction cost.
- Schema evolution is forever. Old events are immutable, so you must upcast old event versions indefinitely.
- Idempotent projections. Consumers may see an event more than once; folding must be idempotent (see Idempotency and Exactly-Once Processing).
- It is the same log primitive that underlies replicated logs, streaming, and durable execution — an ordered, append-only sequence of facts.
Kevin's Billing Ledgers are event sourcing applied to money: an append-only ledger of charges/credits where the balance is a fold, which is exactly why it audits cleanly and resists the billing-exploit class of bugs.
Architecture Position
| Axis | Value |
|---|---|
| Family | Distributed systems primitives |
| Boundary owned | State as append-only events plus read-model separation. |
| Read with | Log-Based Streaming Architecture, Saga Pattern and Distributed Transactions, Idempotency and Exactly-Once Processing |
| Use this page when | auditable state history or separate write/read models are needed |
Timeline
-
2026-07-01 | Architecture category refresh added this page to the Distributed systems primitives family, linked it to Architecture System Map, and kept it standalone because it owns this boundary: State as append-only events plus read-model separation. Source: User request, 2026-07-01
-
2026-06-02 | Page created. Captured append-only events vs CRUD, the command/aggregate/event/projection/query flow, CQRS read/write separation, and implications (eventual consistency, snapshots, schema upcasting, idempotent projections) plus the billing-ledger grounding. Source: compiled from event-sourcing / CQRS literature