Event Sourcing

The core principle is that state changes are persisted as an ordered sequence of events in an append-only store. Once written, an event is never modified or deleted. This provides a complete audit trail of every state transition, from the system's genesis to its current state. Unlike traditional CRUD systems that overwrite data and lose history, the event log is the single source of truth.

An event is a self-contained, immutable record of a fact that has occurred in the past. It is named in the past tense (e.g., ContractSigned, ObligationBreached, PaymentMissed). The current state of any entity is derived by replaying its event stream. This means the database is not the state; it is the log. The state is a transient projection, which can be rebuilt or restructured at any time.

Because the full history is preserved, the system can answer complex temporal questions natively. You can reconstruct the exact state of a contractual obligation at any historical moment using point-in-time retrieval. This eliminates the need for separate temporal tables or complex bitemporal modeling for the core entity state, as the event log itself is a perfect temporal record.

Event Sourcing is often paired with Command Query Responsibility Segregation (CQRS) . Commands (requests to perform an action) are validated against the current state and result in new events. Queries are served by read-optimized projections—materialized views built by subscribing to the event stream. This separation allows for independently scalable, high-performance read models tailored to specific use cases.

Every event is linked to the command that caused it, creating a perfect causal chain from intent to outcome. This is a direct implementation of the happens-before relationship in distributed systems. For legal applications, this provides an unambiguous record of why a state change occurred, which is critical for demonstrating regulatory compliance and resolving disputes over obligation lifecycles.

The current state of an aggregate (a cluster of domain objects treated as a single unit) is not persisted directly. Instead, it is rebuilt by loading its full event stream and sequentially applying each event to an initial state. This replay mechanism is deterministic and allows for the creation of new, unforeseen projections in the future by simply replaying the existing event history against a new projection handler.

The fundamental data structure underlying event sourcing. An append-only log is an immutable, chronologically ordered sequence of records where new entries are written exclusively at the end. Once an event is persisted, it can never be modified or deleted—only compensated by a subsequent event. This property guarantees a complete, tamper-evident audit trail for every contractual state transition.

• Enforces immutability at the storage layer
• Enables point-in-time reconstruction of any prior state
• Contrasts with in-place updates in traditional CRUD systems

An architectural pattern frequently paired with event sourcing that separates write operations (commands that produce events) from read operations (queries against materialized views). In a legal context, commands represent actions like 'Execute Amendment' or 'Record Breach Notice,' while queries retrieve the current obligation state from a denormalized projection.

• Commands are intent-based and may be rejected by validation
• Events are fact-based and represent what has irrevocably occurred
• Enables independent scaling of write and read workloads for high-throughput contract analysis

A specialized database optimized for persisting and retrieving event streams. Unlike general-purpose databases, an event store treats the event log as the primary source of truth. It supports operations like reading all events for a specific aggregate root (e.g., a contract entity) and subscribing to real-time event streams.

• Stores events as an append-only sequence keyed by aggregate identifier
• Supports optimistic concurrency control using version numbers to prevent conflicting writes
• Examples include EventStoreDB, Axon Server, and Kafka-based implementations

A performance optimization technique that periodically persists the full reconstructed state of an aggregate at a specific event version. Instead of replaying thousands of events from the beginning of time to rebuild a contract's current state, the system loads the most recent snapshot and replays only the events that occurred after it.

• Reduces event replay latency for long-lived contractual relationships
• Snapshots are ephemeral caches—the event log remains the authoritative source
• Critical for contracts with high event volumes, such as multi-year service agreements with daily obligations

A consistency model inherent to event-sourced systems where read models (projections) are updated asynchronously after events are persisted. In a legal obligation system, a newly recorded breach event may not immediately appear in a dashboard query. The system guarantees that the projection will eventually reflect the event, typically within milliseconds.

• Accepts temporary staleness in exchange for availability and partition tolerance
• Contrasts with strong consistency where reads always reflect the latest write
• Requires careful design of idempotent projection handlers to handle duplicate event delivery

The practice of managing schema evolution for events over the lifetime of a system. As legal requirements change, the structure of events like 'ObligationFulfilled' may need new fields. Event versioning strategies ensure that old events remain readable while new events carry additional data.

• Upcasting: transforms old event schemas to the current version during replay
• Weak schema: uses flexible serialization formats like JSON with optional fields
• Explicit version markers: embeds a version number in each event type for routing to appropriate handlers