Event sourcing and CQRS

In short: With event sourcing you store not the current state but all events that led to it. CQRS separates writing (commands) from reading (queries).

In more detail: The state results from replaying the events one after another. That gives full history and traceability. For fast queries you build separate read models (projections) from the events.

In Depth

• Event: Immutable fact in past tense (“OrderPlaced”).
• Snapshot: Intermediate state so you do not always replay everything.
• CQRS: Own write model and own optimised read models.
• Advantages: Audit trail, time travel, recomputation, good scaling of reads.
• Disadvantages: Complexity, eventual consistency between write and read model, versioning of events.
• When: Only when history or strong load separation is needed, not as a default.

See also: Distributed transactions: two-phase commit and saga, Domain-driven design