Event Sourcing: When and How

The Audit Trail Pattern

Event sourcing stores state changes as a sequence of events, not as current state. This provides a complete audit trail, enables temporal queries, and supports complex business workflows. It also adds significant complexity.

The traditional approach stores current state. A bank account has a balance of £1,000. Event sourcing stores the history: deposit £500, withdrawal £200, deposit £700. The current balance is the sum of these events.

The event log is append-only. Events are immutable: once written, they cannot be changed. If an event was wrong, you write a correcting event. A mistaken deposit of £10,000 cannot be deleted; it must be reversed with a withdrawal event. The history shows both the mistake and the correction.

When We Use Event Sourcing: We use event sourcing for domains where history matters: financial transactions, insurance claims, and regulatory compliance. We avoid it for domains where only current state matters: user preferences, product catalogues, and session data.

When Event Sourcing Helps

Audit requirements. Financial systems, healthcare records, legal documents — anywhere you must prove what happened and when. Regulators require immutable audit trails.
Complex state machines. Order processing, insurance claims, approval workflows where state transitions matter more than current state.
Temporal queries. "What was the account balance on March 15th?" Event sourcing answers this natively; CRUD databases struggle.

Regulatory Inquiry Example: A financial services client faced a regulatory inquiry that required them to prove every transaction for the past 5 years. Their CRUD database had overwritten old balances. They could not answer simple questions: "What was the balance on this date?" "Who authorised this change?" Event sourcing would have preserved this history.

When Event Sourcing Hurts

Simple CRUD. If your application creates, reads, updates, and deletes without complex workflows, event sourcing is overkill.
Small teams. Event sourcing requires expertise in event schema evolution, projection rebuilding, and consistency models. The learning curve is steep: 6-12 months before the team is productive.
Performance-critical reads. Projections must be maintained or rebuilt. Read latency is higher than direct database queries. For read-heavy systems, event sourcing adds 10-100x latency.

Projection Rebuilding Nightmare: If a projection is wrong (bug in the projection logic), you must rebuild it from the event log. For large event logs (millions of events), rebuilding takes hours or days. During rebuilding, the projection is stale. We mitigate this by maintaining multiple projections, rebuilding offline, and swapping atomically. But this adds operational complexity.

Our Recommendation

Use event sourcing for audit-heavy domains and complex workflows. Avoid it for simple applications and small teams. The pattern is powerful but the complexity tax is real.

Start small. Implement event sourcing for one bounded context, learn from it, and expand if it delivers value. Do not attempt to event-source your entire system at once.

Hybrid Approach: Use event sourcing for the audit-critical part of your domain, and CRUD for the rest. A financial system might use event sourcing for transactions but CRUD for user profiles.

The Audit Trail Pattern

When Event Sourcing Helps

When Event Sourcing Hurts

Our Recommendation

Designing complex workflows?