Event sourcing is an architectural pattern that has gained significant traction in recent years, yet it remains misunderstood by many developers. In this post, we’ll break down what event sourcing is, why it matters, and when you should consider using it.

What is Event Sourcing?

Traditional applications store the current state of their data. When something changes, you update the record in place. Event sourcing flips this model: instead of storing state, you store the sequence of events that led to the current state.

Consider a bank account. In a traditional system, you’d store:

Account #12345: Balance = $1,000

In an event-sourced system, you’d store:

Event 1: AccountOpened { accountId: 12345, initialBalance: 0 }
Event 2: MoneyDeposited { accountId: 12345, amount: 500 }
Event 3: MoneyDeposited { accountId: 12345, amount: 750 }
Event 4: MoneyWithdrawn { accountId: 12345, amount: 250 }

The current balance ($1,000) is derived by replaying these events.

Why Event Sourcing?

1. Complete Audit Trail

Every change is recorded as an immutable event. You can answer questions like “what was the balance on January 15th?” or “who made this change and why?” These questions are often impossible to answer in traditional systems without complex audit logging.

2. Temporal Queries

Since you have the complete history, you can reconstruct the state at any point in time. This is invaluable for debugging, compliance, and analytics.

3. Event-Driven Integration

Events are a natural integration point. Other systems can subscribe to your event stream and react accordingly, enabling loose coupling between services.

4. Flexibility to Reinterpret the Past

When business requirements change, you can create new projections from existing events. Added a new metric to track? Just replay your events through the new projection logic.

The Trade-offs

Event sourcing isn’t free. It comes with complexity:

  • Storage: You’re storing more data (every event vs. just current state)
  • Querying: You need projections for efficient reads
  • Eventual Consistency: Projections may lag behind the event stream
  • Learning Curve: Teams need to think differently about data

When to Use Event Sourcing

Event sourcing shines when:

  • Audit requirements are strict (finance, healthcare, compliance)
  • The history of changes matters as much as current state
  • You need to support multiple read models from the same data
  • Undo/redo functionality is important
  • Integration with other systems via events is a primary concern

It may be overkill when:

  • Your domain is simple CRUD with no complex business rules
  • You don’t need historical queries or audit trails
  • Your team is small and learning curve is a concern

Getting Started

If you’re interested in event sourcing, here are some next steps:

  1. Start small: Pick a single bounded context, not your entire system
  2. Think in events: Model your domain as business events, not database tables
  3. Plan your projections: Design your read models upfront
  4. Consider your infrastructure: You’ll need an event store and projection system

In future posts, we’ll dive deeper into CQRS (Command Query Responsibility Segregation), projection patterns, and how to handle eventual consistency in your applications.

Building an event-sourced system? We’re working on making this easier. Join our pilot program to get early access to Stateful Data.