3 posts tagged with "architecture"

May 2022. I've been at Orus for about two weeks, and it's the day after we signed our first customer. We run into our first real business problem: our customer made a mistake on one of the details, and we need to process an endorsement to their contract.

The catch: at that point, nothing had been built for it. No screen, no data model, no business logic. Just a customer who needed to change what they'd just subscribed to, and a small team improvising the feature in real time. Years later, it's one of the core features of our product, and one I still own with my squad today.

That story sums up what this whole journey has been like for me: every new customer brought its own use case, and we built the product day after day, client after client. The company's growth didn't follow the product. It drove it, and I was lucky enough to have a front-row seat.

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.