Architecture is only valuable when operators feel the difference.
Architecture decisions are product decisions
Event sourcing, CQRS, domain-driven design — these are not resume keywords. They are specific trade-offs that either help or hurt the people who operate the system every day.
The question is never "should we use event sourcing?" The question is "will event sourcing reduce the pain our operators feel during reconciliation, auditing, or incident recovery?"
When event sourcing earns its complexity
Event sourcing stores every state change as an immutable event. This is expensive to build and maintain, but it solves specific problems extremely well:
- Reconciliation: When two systems disagree, events provide a complete history
- Audit compliance: Regulators want to see what happened, when, and why
- Replay and debugging: Replaying events reproduces the exact failure sequence
If your system does not have these problems, event sourcing is overhead.
The operator test
Before adopting any architectural pattern, apply the operator test:
- Name the operator — who is the person whose daily work this pattern will change?
- Describe their current pain — what takes too long, breaks too often?
- Explain how the pattern helps — in terms the operator would understand
If you cannot answer all three, the pattern is not solving a real problem.
Architecture is not a belief system. It is a set of trade-offs that should make life better for the people who operate the system. If it does not, simplify.