Event Sourcing & CQRS · Event Sourcing Concepts
When Not to Use Event Sourcing
Recognize the cases where it adds cost without value.
Event sourcing pays off in domains with complex behavior and valuable history: finance/ledgers, orders and fulfillment, compliance-heavy workflows, collaborative domains needing audit. It's usually a poor fit for CRUD-heavy admin data, simple content management, systems with small teams and tight deadlines, or data that must be easily queried and edited ad hoc. Apply it to specific bounded contexts, not the whole system. Alternatives: CRUD + audit log, temporal tables, CDC streams.
Where event sourcing fits
| Domain | Fit | Reason |
|---|---|---|
| Banking ledger | Strong | History is the product; audit required |
| Order lifecycle | Good | Rich state transitions, integrations |
| User profile settings | Poor | CRUD; history rarely needed |
| Product catalog CMS | Poor | Edit-heavy; ad-hoc queries |
| Collaborative documents | Good (often CRDT/op logs) | Operations matter |
Common pitfalls
- Choosing it for resume-driven reasons.
- Event-sourcing every service in a microservice architecture.
- Underestimating projection and migration work.
Key points
- Use in complex, history-rich domains
- Apply per bounded context
- Consider audit logs or CDC instead
Further reading: Azure Architecture: Event Sourcing pattern
Practice questions
Give two signs a domain may not justify event sourcing.
Answer
Mostly CRUD operations with few business rules, and no real need for historical states beyond a simple audit trail.
What's a lighter alternative when you only need history for auditing?
Answer
Keep CRUD tables and add an append-only audit log or temporal (system-versioned) tables, or stream changes via CDC.
Open in the app to mark lessons complete, take notes and track your progress.