Concepts

This guide introduces the concept of event sourcing and explains how it differs from traditional approaches to storing application state. You'll learn what event sourcing is, when and why it can be useful, how it compares to CRUD-based systems, and in which kinds of domains it can be applied. The goal is to provide an accessible and practical introduction that helps you assess whether event sourcing might be a good fit for your own projects.

CQRS stands for Command Query Responsibility Segregation. The idea is simple: Separate the part of your system that changes data from the part that reads it.

This guide helps you understand where event sourcing can be most effectively applied. While the concept of event sourcing offers powerful capabilities, it is not a one-size-fits-all solution.

This guide explores how to design effective, purpose-driven read models in an event-sourced system. It covers the role of read models in an event-sourced architecture, discusses modeling strategies and trade-offs, and explains how to align projections with use cases. Read models are not simply a reflection of stored events – they are tailored, context-specific representations of current state.

This guide explains how to manage the consistency and freshness of read models in event-sourced systems. While event sourcing allows for clean separation between write operations and derived state, it also introduces the challenge of keeping projections in sync with the event log – especially in distributed environments where reads and writes are decoupled.

This guide explains what eventual consistency means in the context of event-sourced systems and how to design applications that behave correctly even when data is temporarily out of sync. It explores where consistency gaps can occur, how they affect the user experience, and what strategies can be applied to deal with them effectively.

This guide explains how to use snapshots in event-sourced systems to improve performance and reduce overhead during replay. While the event store treats all events as immutable and equally important, applications can introduce snapshots as a way to avoid rebuilding state from the beginning of a stream every time. This is especially useful for aggregates with long histories or systems with high throughput.

This guide explains how to optimize the performance and structure of event replays in event-sourced systems. Replaying events is a fundamental capability of event-sourced architectures. It allows you to rebuild state, regenerate read models, migrate data structures, or recover from errors. While the ability to replay is always available, doing so efficiently – especially at scale – requires careful design.

This guide explores patterns for performing time-based queries in event-sourced systems. Temporal queries are essential for understanding how the system has evolved, analyzing trends, answering retrospective questions, and reconstructing domain state at specific points in time.

This guide explains how to evolve event types and structures in a safe, predictable, and maintainable way. It focuses on practical strategies for versioning events and shows how to preserve compatibility without losing semantic clarity. You'll learn when to introduce new event types, how to handle schema changes, and what to avoid when working with immutable historical data.

This guide explains how to assess and achieve GDPR compliance in event-sourced systems. It addresses the challenges of storing personal data in immutable event streams, outlines the implications for the right to erasure and other GDPR provisions, and offers practical recommendations for designing compliant systems.

This guide describes common mistakes and misunderstandings that arise when working with the event sourcing model. Each section highlights a specific problem, explains its background, and offers guidance on how to avoid or resolve it. The goal is to make it easier to diagnose unexpected behavior and to apply event sourcing concepts correctly in practice.