Offers
EventSourcingDB package
Event-driven domain systems with a traceable history — built on EventSourcingDB by the native web.
“We cannot reconstruct afterwards how a state came to be.”
- Format
- Proof of value in 3 weeks, then iterative rollout
- Who it is for
- Teams with audit requirements, regulated domain logic or complex history
How you notice it
- Answering “how did this value come about?” requires database archaeology.
- Audit evidence is assembled manually from logs and tables.
- Status fields have grown for years and nobody knows all valid transitions.
- The business asks for analyses the current data model cannot answer.
- Intermediate states are overwritten on save — the steps in between are gone.
Outcome
- Assessment whether event sourcing actually fits — including honest pushback
- Reference implementation of one domain slice
- Integration into existing systems and read-model strategy
- Enablement of the internal team incl. operational questions
How we work
01
Week 1 — check the fit
We model one domain slice along its events and check whether event sourcing really carries here. If not, we say so after a week — not after a quarter.
02
Week 2 — reference slice
One domain slice is implemented and runs: events, projections, read models and integration with the existing system.
03
Week 3 — operations & verdict
Backup, event migration, operational questions and a realistic load test. The result is a solid recommendation with an effort range.
04
Then — iterative rollout
Further slices in the same pattern, increasingly led by your team. We accompany instead of delivering forever.
Frequently asked
- Why event sourcing?
- Because the question eventually arrives: who changed what, when — and can you prove it immutably? A system that only stores the current state cannot answer that. We use it where evidence, reconstruction or legal defensibility matter — and we say plainly where it is the wrong answer.
- Do we really need event sourcing?
- Often not. Without a need for traceable history, audit evidence or complex state transitions, a classic data model is enough. That is exactly what we check first.
- Why EventSourcingDB and not a home-grown store?
- Because self-built event stores tend to fail on details: ordering, idempotency, migration, operations. EventSourcingDB by the native web solves that as a product, so we can focus on the domain.
- Do we have to convert the whole system?
- No. We start where history is genuinely valuable and leave the rest as it is. Event-driven and CRUD can coexist.
- How do privacy and deletion obligations work?
- Personal data is not written into events but referenced or kept cryptographically erasable. We settle that during the proof of value, not later.
- What do we have after three weeks?
- A running reference slice, a read-model and integration strategy, clarity on operations and licensing, and a written recommendation with an effort range.
When this does not fit
If your core problem is delivery or operations, event sourcing solves nothing. Production readiness or step-by-step modernisation is the better entry point then.
Often combined with
Background in the article Event sourcing without fear: when it pays off and when it doesn’t.