Event Sourcing

Best Practice: Event Sourcing

Event Sourcing captures every change to application state as an immutable event and appends it to a log. Instead of overwriting a row with its latest value, you record the fact that something happened, then derive current state by replaying the events. The event log becomes the authoritative source of truth. This gives you a complete, auditable history for free, the ability to reconstruct state at any past moment, and a natural fit with event-driven systems and CQRS. Martin Fowler documented the pattern in 2005. It matters when history, auditability, and temporal queries are first-class requirements, but it is more demanding than simple state storage, so it should be a deliberate choice.

Step-by-Step Implementation Guidance

1. Model your domain as events that describe what happened, in past tense, with clear meaning.
2. Choose an append-only event store as the system of record.
3. Rebuild current state by replaying events into in-memory aggregates.
4. Build projections (read models) by subscribing to the event stream.
5. Plan for snapshots so long event streams do not slow down state reconstruction.
6. Version your events, since their schema will evolve over the system's life.
7. Establish clear rules for handling corrections, since events are immutable and never deleted.

Common Mistakes Teams Make When Ignoring This Practice

• Overwriting state and losing the history that audits and analytics later require.
• Adopting event sourcing for simple CRUD where it adds cost without benefit.
• Failing to version events, which breaks replay as schemas change.
• Ignoring snapshotting and suffering slow rebuilds on long streams.
• Trying to edit or delete past events instead of recording compensating events.

Tools and Techniques That Support This Practice

• EventStoreDB, a purpose-built event store.
• Apache Kafka as a durable, replayable event log.
• Axon Framework for event-sourced aggregates and projections.
• Snapshotting and projection libraries within those frameworks.

How This Practice Applies to Different Migration Types

• Cloud Migration: Replay the event log to rebuild state in the new environment with full fidelity.
• Database Migration: Project a new read model from the existing event stream without data loss.
• SaaS Migration: Export the authoritative event history rather than only the current snapshot.
• Codebase Migration: Introduce event sourcing in a new bounded context while leaving legacy state stores intact.

Checklist

• Define domain events in past tense with clear semantics.
• Use an append-only store as the system of record.
• Build read models as projections off the event stream.
• Implement snapshotting for long-lived streams.
• Version events to support schema evolution.
• Define a compensating-event policy for corrections.
• Confirm history and audit needs justify the added complexity.