Event Sourcing - Learning Module

Loading content...

0/273

When to Use Event Sourcing

The Right Tool for the Right Problem

Event sourcing is a powerful pattern—but it's not a universal solution. Like any architectural choice, it introduces both capabilities and costs. Teams that adopt event sourcing without understanding its tradeoffs often struggle with unnecessary complexity, while teams that could benefit from it miss opportunities for simpler solutions to hard problems.

This page synthesizes what we've learned into a practical decision framework. By the end, you'll be able to evaluate whether event sourcing is the right choice for your system and how to introduce it incrementally if it is.

What You Will Learn

By the end of this page, you will understand the core benefits event sourcing provides, the costs and complexities it introduces, which problem domains are ideal candidates, warning signs that suggest simpler approaches, and how to adopt event sourcing incrementally.

Core Benefits of Event Sourcing

Event sourcing provides capabilities that are difficult or impossible to achieve with traditional CRUD systems. These are the genuine superpowers that justify the pattern's complexity.

Unique Capabilities of Event Sourcing

•Complete Audit History — Every state change is recorded with full context: who, what, when, and why. Compliance, debugging, and accountability are built into the architecture, not bolted on as afterthoughts.
•Temporal Queries (Time Travel) — Reconstruct system state at any point in history. Answer questions like 'What was this account's balance on March 15?' or 'How did this order look before the last modification?'
•Event Replay and Projection Rebuilding — Add new read models retroactively by replaying existing events. Fix bugs in projections and recompute correct state from the immutable event log.
•Decoupled Read and Write Models — Optimize reads independently from writes. Build multiple purpose-specific projections from the same events, each tuned for its use case.
•Natural Fit for Event-Driven Architecture — Events are already explicitly modeled. Publishing them to other services for integration is trivial—they already exist.
•Debugging Complex Scenarios — Reproduce production issues by replaying production event streams. Step through state changes to understand exactly what happened.
•Schema Evolution Flexibility — Add new projections without migrations. Reinterpret historical events with new logic. Old events remain forever interpretable.

The Audit Trail Argument

If you're implementing a separate audit log table alongside your main data, you're building half of event sourcing anyway—but with two sources of truth that can diverge. Event sourcing makes the audit log the source of truth, eliminating the duality.

Costs and Complexities

Event sourcing introduces genuine complexity. Pretending otherwise leads to failed projects. Honest accounting of these costs is essential for making good architectural decisions.

Challenges and Costs

•Steeper Learning Curve — Developers must learn new concepts: aggregates, projections, eventual consistency, optimistic concurrency. Teams familiar with CRUD need retraining.
•Eventual Consistency by Default — Read models lag behind writes. Users may not see their changes immediately. This requires careful UX patterns and can confuse developers used to immediate consistency.
•Query Complexity — You can't just SELECT * FROM orders WHERE status = 'pending'. Ad-hoc queries require projections. This slows prototyping and one-off investigations.
•Event Schema Evolution — Events are immutable, but requirements change. Managing backward/forward compatibility across event versions requires discipline.
•Storage Growth — Every change adds to storage instead of replacing. Long-lived systems accumulate significant data. Requires archival strategies.
•GDPR and Data Deletion — 'Right to be forgotten' conflicts with immutable event logs. Crypto-shredding or similar strategies add implementation complexity.
•Debugging Distributed Issues — While event replay helps local debugging, distributed event-sourced systems with multiple projections can be harder to reason about.
•Tooling and Ecosystem — Less mature tooling than CRUD/ORM-based systems. Fewer developers with production experience. Smaller community for support.

Honest Cost Assessment
Cost Category	Impact	Mitigation Strategy
Learning curve	High initial, reduces over time	Team training, pair programming, start with bounded context
Query flexibility	Medium ongoing	Build comprehensive projections, add tooling for ad-hoc analysis
Eventual consistency	Medium UX impact	Design patterns for stale data, optimistic UI updates
Storage costs	Low to Medium	Archival strategies, efficient serialization
GDPR compliance	High if applicable	Crypto-shredding, pseudonymization
Debugging complexity	Variable	Good observability, correlation IDs, replay tools

Ideal Use Cases

Certain problem domains naturally benefit from event sourcing. The pattern shines when its capabilities directly address core business requirements.

Financial and Accounting Systems

Banking, trading, accounting, and payment systems are classic event sourcing domains.

Why it fits:

Regulatory requirements demand complete audit trails
Balance must be provably derived from transactions
Historical state queries are frequent (end-of-month balances, tax periods)
Corrections must be visible, not hidden (accounting journals work this way)

Examples:

Bank account transaction logs
Double-entry accounting ledgers
Trading platforms (order books, position tracking)
Payment processing systems
Cryptocurrency blockchain implementations

Industry evidence: Most banking cores internally work like event-sourced systems—they just don't call it that. Ledgers are append-only by design.

When NOT to Use Event Sourcing

Recognizing when event sourcing is overkill is as important as knowing when it fits. Using it inappropriately adds complexity without corresponding benefits.

Warning Signs: Event Sourcing is Probably Wrong

•Simple CRUD with little business logic — If your system is mostly forms that save data without complex rules, event sourcing adds overhead with no benefit.
•Ad-hoc queries are the primary use case — Reporting dashboards, admin panels, and exploratory analytics are painful without pre-built projections.
•Small team with no event sourcing experience — The learning curve can derail delivery. Consider if the team can afford the investment.
•Strict consistency requirements everywhere — If users absolutely cannot see stale data (rare, but exists), eventual consistency will cause problems.
•No audit or temporal requirements — If you don't need history, audit trails, or time-travel queries, you're paying for features you won't use.
•High data volume with short retention — IoT telemetry with 7-day retention doesn't benefit from immutable logs. Write-heavy, discard-fast patterns are a mismatch.
•Proof of concept or MVP — Ship fast first. Refactor to event sourcing later if requirements demand it.

Red Flags

• 'Let's use event sourcing because it's modern' • 'We might need audit trails someday' • 'Our ORM is slow, maybe events are faster' • 'Everyone at the conference was using it'

Green Flags

• 'Compliance requires complete audit history' • 'We need to answer historical questions frequently' • 'Debugging state changes is currently painful' • 'Multiple services need different views of the same data'

The Strangler Fig Approach

If unsure, start with CRUD for most of your system. When you encounter a bounded context that genuinely needs event sourcing benefits (audit, temporal queries, complex state machines), apply it there. Event sourcing can coexist with traditional data storage in the same system.

Decision Framework

Use this structured approach to evaluate whether event sourcing is appropriate for your system or a specific bounded context within it.

decision-framework.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
// Event Sourcing Decision Framework
// Score each question 0-3: 0=Not at all, 1=Somewhat, 2=Significantly, 3=Critical
 
interface EvaluationCriteria {
  // Benefits that event sourcing provides
  benefitCriteria: {
    auditRequired: number;        // Regulatory/legal audit trail requirements
    temporalQueries: number;      // Need to query historical state
    complexStateMachine: number;  // Many state transitions, compensations
    multipleProjections: number;  // Different services need different views
    eventDrivenIntegration: number; // Publish events to other services
    debuggingPainCurrent: number; // Hard to understand what happened
  };
  
  // Costs that event sourcing introduces
  costCriteria: {
    teamExperience: number;       // Inverse: higher = less experience (more cost)
    adHocQueryNeeds: number;      // Heavy ad-hoc reporting requirements
    consistencyRequirements: number; // Strict immediate consistency needed
    gdprComplexity: number;       // Data deletion requirements
    timeToMarket: number;         // Pressure for fast delivery
  };
}
 
function evaluateEventSourcingFit(criteria: EvaluationCriteria): EvaluationResult {
  const benefitScore = Object.values(criteria.benefitCriteria).reduce((a, b) => a + b, 0);
  const costScore = Object.values(criteria.costCriteria).reduce((a, b) => a + b, 0);
  
  const maxBenefitScore = 18; // 6 criteria * 3 max
  const maxCostScore = 15;    // 5 criteria * 3 max
  
  const benefitPercentage = (benefitScore / maxBenefitScore) * 100;
  const costPercentage = (costScore / maxCostScore) * 100;
  
  // Decision logic
  let recommendation: 'strong-yes' | 'consider' | 'probably-not' | 'no';
  let reasoning: string;
  
  if (benefitPercentage >= 60 && costPercentage <= 40) {
    recommendation = 'strong-yes';
    reasoning = 'High benefit alignment with manageable costs. Event sourcing is a strong fit.';
  } else if (benefitPercentage >= 40 && costPercentage <= 50) {
    recommendation = 'consider';
    reasoning = 'Moderate fit. Consider applying to specific bounded contexts rather than system-wide.';
  } else if (benefitPercentage >= 30 && costPercentage <= 60) {
    recommendation = 'probably-not';
    reasoning = 'Benefits don\'t clearly outweigh costs. CRUD with audit logging may suffice.';
  } else {
    recommendation = 'no';
    reasoning = 'Low benefit alignment and/or high costs. Traditional approaches recommended.';
  }
  
  return {
    benefitScore,
    costScore,
    benefitPercentage,
    costPercentage,
    recommendation,
    reasoning,
    detailedAnalysis: generateDetailedAnalysis(criteria),
  };
}
 
// Example evaluation for an e-commerce order management system
const orderSystemEvaluation: EvaluationCriteria = {
  benefitCriteria: {
    auditRequired: 2,         // Important but not regulated
    temporalQueries: 2,       // "What was the order before modification?"
    complexStateMachine: 3,   // Many states: pending, paid, shipped, returned, etc.
    multipleProjections: 3,   // Warehouse, customer, finance all need different views
    eventDrivenIntegration: 3,// Inventory, shipping, notifications subscribe
    debuggingPainCurrent: 2,  // Customer disputes are hard to investigate
  },
  costCriteria: {
    teamExperience: 2,        // Some engineers have experience
    adHocQueryNeeds: 1,       // Most queries are predefined
    consistencyRequirements: 1, // Users can tolerate brief delay
    gdprComplexity: 1,        // Orders have retention requirements anyway
    timeToMarket: 1,          // Building for long-term platform
  },
};
 
const result = evaluateEventSourcingFit(orderSystemEvaluation);
// Result: 'strong-yes' - Order management is a classic event sourcing fit
 
// Example evaluation for a simple blog CMS
const blogCmsEvaluation: EvaluationCriteria = {
  benefitCriteria: {
    auditRequired: 0,         // No regulatory requirement
    temporalQueries: 1,       // Nice to have version history
    complexStateMachine: 0,   // Draft -> Published, simple
    multipleProjections: 0,   // Single view
    eventDrivenIntegration: 0,// Standalone system
    debuggingPainCurrent: 0,  // Simple enough to understand
  },
  costCriteria: {
    teamExperience: 3,        // Team never used ES
    adHocQueryNeeds: 2,       // Content team wants flexible search
    consistencyRequirements: 0, // Blog can be eventually consistent
    gdprComplexity: 1,        // Some PII in comments
    timeToMarket: 3,          // MVP needed fast
  },
};
 
const blogResult = evaluateEventSourcingFit(blogCmsEvaluation);
// Result: 'no' - Simple CMS doesn't benefit from event sourcing complexity

Incremental Adoption Strategy

You don't have to adopt event sourcing system-wide on day one. An incremental approach reduces risk and allows learning.

Phased Adoption Approach

•Phase 1: Education — Train the team on event sourcing concepts. Build a toy project. Read case studies. Understand the mental model shift before touching production.
•Phase 2: Identify Candidate — Find one bounded context where event sourcing clearly fits: complex state machine, audit requirements, or multi-projection needs. Keep it small and self-contained.
•Phase 3: Implement Pilot — Build the candidate with event sourcing. Start with in-memory or PostgreSQL-based event store—avoid infrastructure complexity initially. Focus on learning.
•Phase 4: Observe and Learn — Run in production for 3-6 months. Document challenges, measure benefits, refine patterns. Build institutional knowledge.
•Phase 5: Expand or Contain — Based on learnings, either expand to additional contexts or decide that CRUD is sufficient elsewhere. Not everything needs event sourcing.

Converting Mermaid diagram...

Hybrid is Normal

Most successful event-sourced systems are hybrid: some bounded contexts use event sourcing, others use CRUD. The contexts publish and subscribe to events via a message broker, but only domains that genuinely benefit bear the event sourcing complexity.

Common Pitfalls to Avoid

Teams new to event sourcing often make predictable mistakes. Learn from others' experience to avoid these traps.

Pitfalls and How to Avoid Them

•Large aggregates with unbounded event streams — Design aggregates to stay small. If events accumulate without bound (user activity), use temporal partitioning or separate event-sourced aggregates from append-only logs.
•Treating events as tables — Events are not normalized database rows. Don't create CRUD-like events (UserUpdated with all fields). Create meaningful business events (UserEmailChanged, UserAddressUpdated).
•Storing mutable references in events — If an event references another entity, store immutable data (name at the time) not just an ID that might point to changed data later.
•Exposing internal events as integration events — Internal domain events and external integration events have different audiences and evolution constraints. Map between them explicitly.
•Rebuilding projections too often — Every schema change shouldn't require projection rebuild. Design projections for evolution. Add fields over time, don't replace structures.
•Ignoring eventual consistency in UX — Users will see stale data. Design for this: optimistic UI updates, loading indicators, 'refresh' affordances. Don't pretend it's immediate.
•Premature optimization with complex infrastructure — Start with PostgreSQL, not Kafka + EventStoreDB + Redis. Add complexity only when you hit real limits.
•Skipping event validation — Once written, events live forever. Validate thoroughly before appending. A malformed event is permanent technical debt.

The CRUD Event Antipattern

Don't create events like UserUpdated { user: {...entire user object...} }. This captures no business meaning and makes evolution impossible. Instead, create specific events: UserEmailChanged, UserProfilePhotoUploaded, UserBillingAddressUpdated. Each event tells a story.

Summary: When to Use Event Sourcing

We've developed a comprehensive understanding of event sourcing: when it shines, when it's overkill, and how to adopt it wisely. Let's consolidate the key insights:

Key Takeaways

•Event sourcing provides unique capabilities — Complete audit trails, temporal queries, projection rebuilding, and natural event-driven integration are difficult to achieve otherwise.
•It introduces real complexity — Learning curve, eventual consistency, query limitations, and schema evolution challenges require investment and expertise.
•Ideal domains have clear indicators — Financial systems, compliance-heavy domains, complex state machines, and multi-projection needs are strong candidates.
•Many systems don't need it — Simple CRUD, ad-hoc query-heavy, small teams, or MVP phases are often better served by traditional approaches.
•Use the decision framework — Score benefits vs costs systematically. Let requirements drive architecture, not trends.
•Adopt incrementally — Start with one bounded context. Learn. Expand or contain based on real experience, not theory.
•Avoid common pitfalls — Keep aggregates small, design meaningful events, handle eventual consistency in UX, start with simple infrastructure.

Module Complete

You've completed the Event Sourcing module. You now understand:

How events become the source of truth instead of current state
Event store design, storage models, and consistency guarantees
Rebuilding state through rehydration and time-travel queries
Optimizing with snapshots while maintaining correctness
When event sourcing is the right choice and how to adopt it wisely

Event sourcing is a powerful pattern when applied appropriately. Use these tools to make informed architectural decisions and avoid both missing opportunities and unnecessary complexity.

Module Complete

You now have a comprehensive understanding of event sourcing: the paradigm shift to events as truth, practical implementation with event stores and snapshots, and the wisdom to apply it appropriately. Use this knowledge to design systems that leverage event sourcing's superpowers while avoiding its pitfalls.