The Complexity Cost
Event Sourcing and CQRS are powerful, but they introduce significant complexity. Before adopting them, you should understand the costs clearly.
Operational complexity:
- You now maintain two databases (Event Store + Read Model) instead of one.
- You must handle projection failures, replay lag, and schema evolution of events.
- Debugging requires understanding the projection pipeline, not just the database.
Event schema evolution is hard. Once an event is written to the store, it is immutable. But your understanding of the domain changes over time. If you rename a field in OrderPlaced, every projector that reads that event must handle both the old and new schema. This requires upcasting — transforming old event formats into new ones at read time — which adds complexity to every consumer.
Eventual consistency requires UI design changes. Users who submit a form and immediately see stale data will report it as a bug. Your frontend must be designed to handle this gracefully (optimistic updates, loading states, version polling).
When It's Worth It
Event Sourcing pays off when:
- Auditability is a hard requirement (finance, healthcare, legal).
- The domain is complex with many business rules and state transitions.
- Multiple independent consumers need to derive different views from the same data.
- Temporal queries ("what was the state at time T?") are a real use case.
It is overkill for simple CRUD applications — a blog, a settings page, a user profile form. Start with CRUD. Introduce Event Sourcing only when the complexity it solves outweighs the complexity it introduces.
If an interviewer asks "Would you use Event Sourcing for this system?", the strongest answer demonstrates judgment, not enthusiasm. Acknowledge the benefits, then explicitly state the costs and the threshold at which the trade-off becomes favorable. Engineers who reflexively say "yes, Event Sourcing everywhere" signal inexperience. Engineers who can articulate when not to use it signal architectural maturity.