Event Sourcing

The fundamental data store is an append-only sequence of events. Each event is a factual record of something that happened in the system (e.g., OrderPlaced, PaymentProcessed). Once written, events are never updated or deleted. This provides a complete, verifiable audit trail of all system activity, serving as the single source of truth for reconstructing state.

The current state of any entity is not stored directly but is derived by replaying its event history. A projection or aggregate processes the sequence of events in order, applying the logic of each to build up the current state.

• Example: To get a customer's current balance, you start from 0 and apply all Deposit and Withdrawal events for that customer.
• This enables temporal querying—you can reconstruct the state of the system at any point in the past by replaying events up to that moment.

Event sourcing is often paired with Command Query Responsibility Segregation (CQRS). The write model handles commands by validating business rules and persisting new events. The read model consists of projections that listen to events and update optimized, query-friendly views (e.g., in a SQL database or a document store). This separation allows each model to be optimized for its specific purpose: consistency for writes and performance for reads.

Events are not just for state reconstruction; they are first-class messages for system integration. Other services or components can subscribe to the event stream to react to changes asynchronously. This enables a loosely coupled, reactive architecture where:

• A ShipmentCreated event can trigger inventory updates.
• A UserRegistered event can initiate a welcome email workflow.
• This pattern is the foundation for event-driven microservices.

Because the entire history is stored, you can answer questions that are impossible with a traditional CRUD database:

• What was the state of this order at 3 PM yesterday?
• What sequence of actions led to this specific system state?
• Show me all changes made by user X last week. This capability is invaluable for auditing, compliance, and debugging complex business processes. You can effectively "time-travel" through the system's history.

The immutable event log is a complete, non-repudiable audit log by design. Every state change is captured with its timestamp, source command, and user context. This is critical for regulated industries (finance, healthcare) where proving the lineage of data and decisions is mandatory. There is no need for separate audit tables or triggers, as the core data model itself fulfills this requirement.

CQRS is an architectural pattern that separates the models for updating information (commands) from the models for reading information (queries). It is frequently paired with event sourcing.

• Commands are intent to change state, which are validated and then result in the emission of events.
• Queries are served from optimized, denormalized read models that are updated asynchronously by processing the event stream.
• This separation allows the read and write sides to scale independently and be optimized for their specific workloads.

The Saga pattern is a design pattern for managing data consistency across multiple services in a distributed transaction. Instead of a traditional ACID transaction, it uses a sequence of local transactions, each with a compensating transaction for rollback.

• In an event-sourced system, each local transaction can emit events.
• The saga's coordinator or participants react to these events to trigger the next step or a compensating action.
• This creates a reliable, auditable workflow for long-running business processes that is resilient to partial failures.

Event-Driven Architecture (EDA) is a paradigm where the flow of the program is determined by events—significant changes in state. Event sourcing is a specific implementation of EDA focused on state persistence.

• Events are immutable records of something that happened.
• Producers publish events without knowledge of the consumers.
• Consumers subscribe to events and react asynchronously.
• This creates loosely coupled, highly scalable systems where new functionality can be added by simply subscribing to existing event streams.

A state machine is a computational model that defines a finite number of states, the transitions between those states, and the actions triggered by those transitions. It is a core construct for modeling business logic in an event-sourced system.

• The current state is derived by applying the entire sequence of past events.
• Incoming commands are validated against the current state and the state machine's rules.
• If valid, the command results in a state transition, which is recorded as a new event.
• This ensures all business rules are centrally encoded and the system's behavior is deterministic and replayable.

Eventual consistency is a consistency model used in distributed systems where, given enough time without new updates, all replicas of a data item will converge to the same value. It is a common trade-off in systems using event sourcing and CQRS.

• When an event is emitted, the write model is immediately updated.
• Read models are updated asynchronously by processing the event stream, causing a temporary lag between the write and read perspectives.
• This lag is acceptable for many business domains and enables high availability and partition tolerance, as described by the CAP theorem.

Change Data Capture (CDC) is a technique that identifies and tracks changes in a database (inserts, updates, deletes) and streams them as events. It is often compared to event sourcing but operates at the infrastructure layer.

• Event Sourcing stores business-level events as the system of record.
• CDC captures technical, row-level changes from an existing database's transaction log (e.g., MySQL binlog, PostgreSQL WAL).
• CDC can be used to create an event stream from a legacy system, enabling gradual migration towards an event-driven architecture or to populate read models in a CQRS setup.