3 posts tagged with "event-sourcing"

On our last project, the way we planned, built and reviewed the work changed more than the code itself. AI agents were part of the project from day one, no longer a tool we used from time to time. This post is about that method.

The project was a rebuild of our organizations module, one of the oldest and most central parts of the codebase. It models partners, brokers and their members, and it sits upstream of most of what the platform does. Replacing it had been on the backlog for a while. It was the kind of project that stays "not yet" because the risk surface is high: everything touches it, and touching it wrong has cascading consequences.

We shipped it. We sized it at around 30 working days, shipped in about 20, and every milestone landed ahead of its ETA. But the schedule is not the point. The method is, and it is one we want to apply to all our next projects, not just this one.

In our previous article, we introduced how event sourcing works at Orus. Instead of mutating rows in a database, we append immutable events to an event store. We then derive the current state of any entity (a contract, an invoice, a user, or whatever...) by replaying those events through a reducer.

That covers writing data and reading it. But there's a third thing every real application needs to do: react to what happened.

When a contract is signed, an invoice needs to be generated. When a payment fails, a broker needs to be notified. When a user uploads a document, an AI analysis should kick off. None of that happens by itself just because you appended an event.

This calls for additional infrastructure.

Event sourcing is rarely used as the foundation of the whole system, but at Orus, we had the chance to start from scratch, and think things through before writing the first line of code.

Insurance is complicated, and we need to know exactly what happened at any given time.

When a claim is filed, a contract renewed, or a coverage added, the "current state" of a database row isn't enough. We need to answer: Who changed this? When? Why? And what did the contract look like exactly before that change?

In a standard CRUD application, you might add an audit log table. But audit logs rot. They get out of sync with the actual data. In event sourcing, the audit log is the data.

We decided early on to build our backend (TypeScript/Node.js) on a 100% event sourced architecture. It wasn’t the easiest path, but it was the right one for our domain.