Event Sourcing

The core tenet of event sourcing is that all changes to application state are stored as a sequence of immutable events in an append-only log. This log is the system of record. The current state is a derived projection, calculated by replaying the entire event history. This provides a complete audit trail and enables powerful debugging, as every state change has an explicit, stored cause.

• Example: In a banking system, events are AccountOpened, MoneyDeposited, MoneyWithdrawn. The current balance is the sum of all deposit and withdrawal events for that account.

Any past or present state of the system can be reconstructed by replaying the event log from the beginning up to a desired point in time. This is performed by an event handler or projection that processes each event in order to build the current state (e.g., a balance, an inventory count). This allows for:

• Temporal Querying: Querying the state of the system as it was at any historical point.
• Debugging & Auditing: Precisely tracing how any state was reached.
• Building New Projections: Creating new read models (views) from the existing event history without modifying the original data.

Event sourcing provides a natural mechanism for rollback and state reversion. Since state is derived from events, reverting to a previous state involves:

1. Identifying a checkpoint (a specific event sequence number or timestamp).
2. Truncating or ignoring subsequent events.
3. Replaying events only up to that checkpoint.

This is fundamentally different from traditional CRUD systems where an update overwrites previous state. It enables compensating transactions to be modeled as new events (e.g., WithdrawalCancelled) that semantically reverse a prior action, rather than attempting to directly mutate past data.

Event sourcing is frequently paired with Command Query Responsibility Segregation (CQRS). Commands (writes) result in the validation and persistence of new events to the log. Queries (reads) are served from materialized views or projections that are optimized for specific query patterns and asynchronously updated from the event stream. This separation allows:

• Optimized Read Performance: Read models can be denormalized and indexed for fast queries.
• Independent Scaling: Write (event storage) and read (projection) systems can scale independently.
• Flexibility: Multiple different read models can be built from the same event stream.

As business requirements change, the structure of events (event schema) must evolve. Event sourcing systems require strategies for schema evolution to handle events stored in an old format. Common patterns include:

• Upcasting: Transforming an old-format event into a new-format event during replay.
• Event Adapters: Wrappers that translate between different schema versions.
• Maintaining Backwards Compatibility: Designing new event schemas to be additive, not destructive, to old ones.

This ensures the immutable event log remains readable and replayable indefinitely, even as the application logic changes around it.

For reliable state reconstruction, the processing of events must be deterministic. Given the same initial state and the same sequence of events, the system must always produce the same final state. This requires:

• Pure Projection Logic: Event handlers should avoid side-effects that depend on external, variable state (e.g., random number generation, current time) during replay.
• Ordering Guarantees: Events must have a consistent, preserved order, often using a monotonically increasing sequence number.
• Idempotent Processing: Systems must be resilient to the same event being processed more than once, which is critical for recovery and at-least-once delivery semantics in distributed systems.

CQRS is an architectural pattern that separates the model for updating information (commands) from the model for reading information (queries). This separation is synergistic with event sourcing.

• Commands mutate state by appending events to the immutable log.
• Queries read from optimized, denormalized materialized views derived from the event log.
• During a rollback, the command side can truncate or compensate for events, while query-side views can be rebuilt from the corrected event sequence, ensuring read consistency.

The Saga pattern manages long-running, distributed transactions by breaking them into a sequence of local transactions. Each local transaction has a corresponding compensating transaction to semantically undo its effects if a later step fails.

• Unlike event sourcing's temporal rollback, Sagas provide a business-level rollback.
• Critical for agentic systems where an action (e.g., a tool call) has irreversible external side effects.
• Example: An agent booking a flight (T1) and then a hotel (T2). If T2 fails, a compensating transaction cancels T1.

Deterministic execution is a system property where, given the same initial state and sequence of inputs, an agent or process will always produce identical outputs and state transitions.

• Absolute prerequisite for reliable event replay and state reconstruction in event-sourced systems.
• Ensures that rolling back to a checkpoint and replaying events leads to the exact same state as the original execution.
• Non-determinism (e.g., random number generation, time-based logic) must be explicitly captured as events in the log.

State machine replication is a fundamental method for implementing fault-tolerant services. It ensures a collection of replicas start from the same state and execute the same commands in the same total order.

• The event log in event sourcing acts as the replicated log.
• Consensus protocols like Raft or Paxos are used to agree on the order of events (commands) across replicas.
• Enables high availability and consistent rollback across all replicas in a distributed agentic system.

A compensating transaction is a logically inverse operation executed to semantically undo the effects of a previously committed transaction in a distributed system.

• Used when a simple state reversion is impossible (e.g., after an email is sent, a payment is processed).
• Core mechanism within the Saga pattern.
• For an event-sourced agent, a compensating action would itself be recorded as a new event in the log (e.g., PaymentRefundInitiated), updating the current state rather than deleting past events.

An idempotent action is an operation that can be applied multiple times without changing the result beyond the initial application.

• Critical property for safe retries and rollback/replay mechanisms.
• In event sourcing, if an event handler is idempotent, replaying the event log after a crash or rollback will not cause duplicate side effects.
• Example: SetUserStatus(status='active') is idempotent; IncrementCounter() is not. Agentic tool calls should be designed for idempotency where possible.