Introduction
Event sourcing is one of those architectural patterns that sounds amazing in theory but can be challenging in practice. After running an event-sourced payment system in production for 2 years, I’ve learned when it’s worth the complexity and when it’s not.
What is Event Sourcing?
Instead of storing the current state of your data, event sourcing stores a sequence of events that led to that state. Think of it like a bank statement: instead of just showing your current balance, it shows every transaction that got you there.
The Good Parts
Complete Audit Trail
This is the killer feature. When a customer reports a payment issue, I can replay every event and see exactly what happened. No more “I don’t know why the system did that.”
Time Travel Debugging
Being able to replay events up to a specific point in time is incredibly powerful for debugging. I can reproduce production issues locally by replaying the event stream.
Flexibility in Projections
Need a new view of your data? Just create a new projection and replay the events. No complex database migrations required.
The Hard Parts
Complexity
Event sourcing adds significant complexity. You need to think about:
- Event versioning and schema evolution
- Eventual consistency
- Projection rebuilding
- Event store performance
Eventual Consistency
Your projections are eventually consistent with the event stream. This can be confusing for developers used to immediate consistency.
Debugging is Different
When something goes wrong, you can’t just look at the database. You need to understand the event stream and projections.
When to Use Event Sourcing
Based on my experience, event sourcing is worth it when:
- Audit trail is critical: Financial systems, healthcare, compliance-heavy domains
- Complex business logic: When you need to understand how you got to the current state
- Multiple views of data: When different parts of the system need different representations
When NOT to Use Event Sourcing
Don’t use event sourcing for:
- Simple CRUD applications: The complexity isn’t worth it
- Prototypes or MVPs: Start simple, add complexity later if needed
- When the team isn’t ready: Event sourcing requires a mental shift
Practical Tips
Start Small
Don’t event-source your entire system. Start with one bounded context where the benefits are clear.
Invest in Tooling
Build good tooling for:
- Viewing events
- Replaying events
- Monitoring projection lag
- Event versioning
Plan for Schema Evolution
Events are immutable, but your business logic will change. Plan for event versioning from day one.
Conclusion
Event sourcing is a powerful pattern, but it’s not a silver bullet. Use it when the benefits (audit trail, time travel, flexibility) outweigh the complexity. For most applications, traditional state-based storage is simpler and sufficient.
The key is understanding the trade-offs and making an informed decision based on your specific requirements.