All insights
ArchitectureData5 min read
Event sourcing without the cult
Event sourcing is a useful pattern that has acquired the energy of a religion. There's a sober version that actually pays off.
Event sourcing — storing the events that changed your state instead of just the current state — has real benefits. It also has true believers who'll tell you it solves all your problems, which it doesn't, and a complexity cost most teams underestimate.
Where it earns its keep
- Domains where you need to know how the state got here, not just what it is.
- Audit requirements that can't accept reconstruction from logs.
- Workflows where replaying past events is genuinely useful for testing.
Where it bites you
Schema evolution becomes a chore. Reporting requires building projections that you'll have to maintain. New engineers will be confused by what's source of truth versus what's derived. Many teams use event sourcing to solve problems they don't have.
Use it because you need history. Not because the pattern is fashionable.