Architecture rationale
Event sourcing: when it pays off — and when it does not.
Classic systems store what is true right now. Not why it is true. This page explains what that gap really costs — and when it does not justify a different architecture.
What the system is — and what happened in it.
Every domain system carries two truths. One is the domain model: what applies, which rules hold, what the current state is. The other is history: which events, in which order, led there.
Most systems store only the first. An update overwrites the old value, and with it reason, causality and context disappear. What remains is state without explanation — and the explanation is exactly what gets asked for when it matters.
State-oriented
The customer discount is 12%. Since when, by whom and under which rule — unknown.
Event-oriented
Discount set to 12% on 14 March, triggered by the annual agreement, approved by sales leadership. State follows from that.
Two perspectives on the same problem.
Leadership and engineering experience missing history differently — the cause is identical.
What it costs and risks
Obligation to prove, without proof
Auditors, customers or regulators ask for the state at a given date. The answer is assembled by hand from logs, backups and memory — several person-days per request.
Rule changes become projects
A new calculation rule means migration, test window, downtime and risk. Business decisions slip because technology makes them expensive.
Knowledge sits with people
Two or three people know why the system behaves the way it does. Onboarding takes months, holidays become a risk, external help costs more than it should.
AI initiatives stall on explainability
Once decisions are automated, traceability becomes an approval condition. Without it, the project never leaves pilot status.
The pain points as they actually feel.
Not as architecture vocabulary, but as sentences people really say in meetings.
“Why was the price at that value in March? Nobody can tell us.”
Lost history: only the current state is stored.
Events are the store. State at any point in time is replayed, not reconstructed.
“We can see it was changed. We do not know why.”
Lost causality: trigger and context of a change are missing.
Every event carries intent, trigger and context — not just the new value.
“That rule change needs a migration project and a maintenance window.”
Schema and data migrations as the default path for business changes.
New evaluations and rules run on the existing event sequence. The past does not need rewriting.
“The reporting numbers do not match the system.”
Dual writes: several stores that drift apart.
One source of truth from which all views are derived — including reporting and search.
“Only the colleague who built it back then knows that.”
Domain knowledge lives in heads instead of in the model.
The domain model becomes explicit, named and versionable. Onboarding reads instead of asking.
“Let us quickly add some logging for the audit.”
Audit layers bolted on afterwards — incomplete and expensive to maintain.
Auditability emerges structurally, because history carries the system instead of running beside it.
“We ship slower than three years ago, with more people.”
Growing fear of regressions in a system that has grown organically.
Clear domain boundaries, derivable views and replay lower the cost of every change.
“We cannot explain why the system decided that way.”
Opaque state — especially critical once decisions are automated.
Decision, context and outcome are recorded individually and can be replayed.
None of these costs appear in a budget line. They show up as “other IT costs”, as consulting, or as extended time-to-market — and compound over years.
What the organisation actually gets.
Not elegance, but properties that show up in cost and risk.
Auditability by design
Tamper resistance and provability come from the structure, not from a bolted-on audit trail that has to be maintained and defended.
New logic on existing history
A changed business rule can be evaluated retroactively against the existing event sequence — without data migration and without losing the old view.
State at any point in time
Reporting, analytics and later AI features get a solid basis instead of a snapshot export.
Explicit, versionable domain model
Business and engineering speak the same terms. Misunderstandings surface earlier, alignment is faster, key-person risk drops.
Explainable for years
Systems stay understandable and evolvable long after the original team has moved on.
Replay instead of speculation
Debugging, what-if analysis and comparing two strategies run on real data rather than assumptions.
Why regulation is the most honest reason for event sourcing.
Event sourcing is rarely bought for the technology. It is bought because someone has to answer a question that only an immutable history can answer.
NIS2, the EU AI Act and the Cyber Resilience Act demand different things — but all three end in the same place: who decided what, when, and can you prove it? That is not a documentation question. It is the question of whether the system knows its own history.
Regulation is the recurring occasion, not the actual topic. The duties arrive in stages and keep changing — every new stage asks the same basic question again. An architecture built on domain events answers the next round with the same foundation. One that only stores state starts from scratch every time.
That is why we do not recommend event sourcing out of enthusiasm for technology, but where these questions are foreseeable. And we say just as clearly when a clean data model with a change log is enough — that is more often than the scene admits.
The implementation view in detail: NIS2, EU AI Act and Cyber Resilience Act.
Total cost of ownership: the visible cost is only the entry ticket.
The real drivers appear across a system's actual lifetime — which is usually longer than planned.
- Maintenance and evolutionRunning costs rise because every change needs more safeguarding than the last one.
- Forensics during incidentsEvery compliance request and every incident occupies senior people for days — the same people who would otherwise be shipping.
- Delayed releasesFear of side effects pushes dates. The revenue effect never shows up in an IT cost centre.
- External expertiseOnce domain knowledge has left the building, it gets bought back — permanently, at daily rates.
- Failed AI initiativesAgent projects rarely fail on the model. They fail on missing explainability and missing trust.
How long does enterprise software really stay?
- Core systems and important custom applications
- 10–15 years
- ERP and comparable central systems
- 12–20 years
- Legacy estate in large organisations today
- 15–21 years
Software is rarely replaced because it expired technically. It is replaced when the pain exceeds the effort of replacing it. Until then it lives longer than planned — and gets more expensive.
AI agents turn this into an approval question.
Agentic systems make decisions, call tools and act over long horizons. Classic state stores structurally do not fit that.
Problem
- A decision overwrites state — reason and context are gone afterwards.
- On errors or compliance questions, what the agent knew at that moment cannot be reconstructed.
- Multiple agents create race conditions and side effects nobody can trace.
- Debugging multi-step runs gets extremely expensive because every run is unique.
With event sourcing
- Complete, traceable history of every action and every tool call.
- Reconstruction of the exact context at any point during execution.
- Coordination of multiple agents over the same event sequence instead of shared state.
- Replay for debugging, experiments and a solid comparison of two strategies.
And when you do not need this.
Worth it when
- Your systems are meant to live longer than seven to eight years
- You operate in regulated or trust-critical domains
- You want AI agents involved in decision processes
- You already feel the cost of “we no longer know why the state is what it is”
- Agility for you means changing rules without destroying the past
Not needed when
- You build simple systems with short lifetimes and low domain complexity
- The current pain — missing history, audit effort, expensive rule changes — is small enough
- A clean data model with a proper change log fully covers your requirements
Frequently asked questions
- What exactly can we produce under audit?
- A complete, tamper-evident sequence of domain events: who triggered which decision, when, in what order, with what data. Plus the state of the system at any point in time — reconstructed, not asserted. That is the difference between documentation and provability: a system that only stores the current state cannot answer “why does it look like this today?”.
- When is event sourcing worth it?
- When traceability, auditability or frequent rule changes turn into a cost factor and the system runs for many years. For simple, short-lived systems the effort is not justified.
- How long does enterprise software realistically live?
- Core systems and important custom applications typically stay 10 to 15 years, ERP and comparable central systems often 12 to 20 years. Legacy estate in large organisations averages 15 to 21 years today.
- What is the difference between event sourcing and an audit log?
- An audit log runs beside the system and can be incomplete or altered afterwards. With event sourcing the events are the system: state is derived from them, so history cannot bypass operations.
- Do we need CQRS or domain-driven design for this?
- Not strictly, but the combination is common. CQRS separates write and read models, domain-driven design provides the boundaries. Event modeling is how both get worked out with the business before code exists.
- Can we introduce this in an existing system?
- Usually step by step: one bounded area first, the rest stays untouched. That is the common entry point for modernisation — not a rewrite of the entire estate.
The actual question
How expensive will it be in eight to twelve years if your system does not store the history and the reasoning behind decisions — especially once AI agents become part of those decisions?
Worked examples: Who promised what? When nobody can reconstruct what happened and Who skipped the credit check? Order fulfilment across five systems.
Further reading: when event sourcing pays off, event modeling as an adoption tool and modernising a monolith without a rewrite.