Event Sourcing for the Other 95%

Once upon a time, a CTO told me something that stuck with me.

"We want to use event sourcing. But we have a hard time finding engineers who know how to do it. Is it just a niche?"

I've been building event-driven systems for over fifteen years. I wrote the first lines of what became Axon Framework because I was tired of watching CRUD systems quietly lose information that mattered. Since then, that code has been downloaded more than fifty million times.

And still, the CTO's question is fair.

Here is the strange part. After fifteen years of documentation, articles, talks, and hard-won knowledge out there, the honest answer is still yes. It has stayed a niche. I think I may have found out why, and part of that is on me.

I'll come back to my own role. First, let me explain why the question matters more now than it did a year ago.

The market walked in on its own

Something has shifted lately. Not because we finally convinced anyone, but because the market came knocking on our door.

AI agents make decisions that nobody can fully predict. Those decisions need to be recorded, explained, and replayed. Regulators increasingly expect the full history of what happened, not a number worked out after the fact. And async, streaming, event-driven design has quietly become the default instead of the exception.

Every one of those trends points at the same thing. An immutable record of what happened. That is event sourcing. Nobody set out to make it relevant. It just happens to be where these forces meet, refined and hardened over fifteen years.

So the timing is good. But there is a catch.

AI will demand things that most systems can't give. It needs to explain decisions after they were made. It needs the data together with the context that gives the data meaning. It brings a number of agents that will put real pressure on how systems scale. And when an agent gets something wrong, the system has to recover gracefully. Event sourcing answers all of those.

But only if more than five percent of us can actually use it.

No single step is hard

I travel a lot. I can walk through an airport like a zombie. A bad night's sleep, no coffee, it doesn't matter. Passport, security, gate, boarding. My feet know the way.

One day, in the middle of all that, I noticed an elderly gentleman standing still. He had a piece of paper in his hand and kept looking around, clearly lost. I went over and asked if I could help. He didn't understand a word I said. But he showed me his boarding pass.

He was on the wrong side of the airport, with no idea where to go. I walked him over to the service desk. He couldn't thank me in any language I knew, so he pressed both hands to his heart instead. 

Nothing about that airport was hard. Not for me. For him, every sign and every corridor was one more thing he could not read, and it added up to being completely lost in a place I move through without thinking.

That is when it clicked. This is exactly how a developer feels trying to navigate event sourcing. Not one hard thing. Just a hundred small unknowns that pile up until the whole thing feels like too much.

That gentleman never wanted to learn the airport. He only wanted to reach his gate. To get to his destination. There is a deeper version of the same problem in what we ask of developers. For fifteen years, we have been telling them to build a car when all they wanted to do was drive one.

We, the people who love this stuff, know the engine. Aggregates, projections, snapshots, replay logic. Most developers don't want any of that. They want to get from A to B. And we keep telling them they have to finish mechanic school first.

The ladder moves up

For the first time, AI can carry the hardest parts of event sourcing for us.

For most of computing history, every step up the ladder let more people build software. Machine code. Assembly. Then languages like Java and C#. Each layer hid the one below it, and each time, more people could build.

AI is adding another rung. It writes the boilerplate. The developer's job shifts from knowing how to build something to knowing whether the right thing was built. From writing the code to describing what the code should do.

The intricate parts of event sourcing, the schema evolution, the snapshot strategy, the projection rebuild, are exactly the kind of work a machine can take over. The developer stops being the mechanic and becomes the person who checks that the car drives.

Event modeling is the specification

That description of what the code should do already has a name. Event modeling.

Commands, events, views, and the states a user moves through. Plain business concepts that say what should happen, not how. Declarative. Domain-aware. Exactly the kind of input a machine needs to generate the rest. Event modeling could become the way humans tell machines what to build.

If, and it is a real if, the practice can lighten up enough to deserve the role.

Two rooms, two jobs

This is where I want to give event modeling a small push.

Right now, we tend to do all of it the same way. Everyone in one room, a wall of stickies, two days on the calendar. And for part of the work, that is exactly right.

There are really two jobs hiding inside that one format.

The first is exploration. Finding the shape of the thing. Where the high points are, where the surprises hide, what the story actually is. That work is best done in a room, with the whole team, stickies on a wall, everyone talking over each other. It is high bandwidth and a little messy, and that is the point. It is worth two days. Once.

The second job is the detail. And this is where the sticky wall betrays us. Working out the details on a wall of paper is slow, fragile, and almost impossible to hand off. The moment the room empties, the shared understanding starts to fade, and half of it lived in the conversation rather than on the wall.

The detail belongs at the desk. Not with stickies, but with tools built for the purpose. Written. Digital. Precise enough to be passed from one person to another, or to a coding agent, without booking a two-day meeting to decode it. This is the part where AI can draft and the team refines. Lighter sessions, more often, instead of one heavy ritual now and then.

Keep the room for what the room is good at. Move the details to the desk. Do not use the heavy format for both.

The frameworks, ours included

Modeling is one half of the shift. The frameworks are the other.

I should know how easy it is to get this wrong. For fifteen years I have been building Axon Framework to make event sourcing easier, and I'm proud of a lot of it. Making the car easier to build was worth doing, and I would do it again. But I've come to realize that it was only ever half the job. It made building the car easier. It never made it easier to just drive one. 

It gives people better wrenches. Cleaner ways to wire up an aggregate. Nicer abstractions over the event store. All of it still assumes you want to be under the hood in the first place. For the person who just wanted to get from A to B, it made the workshop tidier. It never handed them the keys.

That distinction matters. Doing event sourcing is knowing how to build the car. Applying event sourcing is getting the outcomes: the audit trail, the replay, the memory an AI agent can rely on. Most people only ever needed the second. Axon Framework, like most of what our field built, was made for the first.

So the next generation has to flip that. Stop exposing the mechanics. Expose the intent. Today, to turn down an order from a closed account, you load every event for that account, replay them to work out whether it is closed, and only then reject the command. Instead, you should be able to say "reject this order when the account is closed" and let the framework work out the rest: the state, the sourcing, the command model. You declare the rule. The framework hides the event sourcing.

That is the shift I want to lead next. Not a tidier workshop. A framework you can drive. 

The dialect

I said modeling and frameworks were the two halves of the shift. That was not the whole truth. There is a third, and it is the hardest, because it is not a tool anyone can fix for us. It is us. The community. 

Of everything here, the language may matter most. Not just one more barrier. Maybe the biggest one. And I helped build it. So did every one of us who ever spoke it fluently. We, the mechanics, raised this wall, and we keep it standing.

We have built a beautiful dialect. Aggregate. Bounded Context. Saga. Projection. Upcasting. Rehydration. Tombstone. Decider. Every one of those words is precise. Every one is useful once you know it. Together, to someone new, they are a wall. An airport full of signs in a language you cannot read, and your gate somewhere on the far side.

My favorite example is one I still stumble over. "The current state is a left fold over the event stream." Left fold. It takes me straight back to kindergarten, when our shoes had an L and an R on them so we knew which foot was which. I still need that trick before I can tell what the sentence means. And I wrote a framework for this.

If it trips me up after fifteen years, imagine what it does to someone on their first day.

Shu, Ha, Ri

If our words are how we keep newcomers out, the way we teach is how we could let them in. 

There is an old idea from Japanese martial arts that describes how people learn a craft. Shu, Ha, Ri.

Shu means follow the rule. You obey the form exactly. No improvising yet.

Ha means break the rule. Once the form is second nature, you start to adapt it.

Ri means define the rule. You understand it well enough to set the form that others will follow.

Most of us in this field are somewhere in Ha. We know the patterns well enough to bend them. A rare few reach Ri and write the rules the rest of us live by.

Here is the thing we keep forgetting. A newcomer is in Shu. They don't need our nuance. They need a clear rule to follow first. And for years we have handed them nuance instead. The whole dialect, the whole debate, before they have even posted their first sticky.

So the rule I now use in workshops is small. Avoid the jargon unless everyone in the room already speaks it. Use the words the business uses. Order. Payment. Shipment. Refund. Give the newcomer a rule they can follow before you show them how to break it.

Simple over interesting

We love the elegant solutions. The mathematically clean ones. And they are beautiful. But beautiful is for craft. Simple is for adoption.

We don't feel the barrier, because we already speak the language. That is exactly what makes us the 5%. And it means the barrier is ours to remove, not theirs to climb.

Back to the question

So back to that CTO. Is it just a niche?

For fifteen years I built tools that made it easier to be a mechanic. I am now on a mission to build the thing I never did: tools that let people drive.

And here is the part I find almost funny. The reason we suddenly need this, AI, is the very thing that can finally deliver it. The force that raised the bar is the same force that can lower it. AI is what makes event sourcing matter to the other 95%, and AI is what can hide the engine so they never have to look at it.

That is what I want to bring to the framework I have spent fifteen years on. Not more power for the mechanics. Simplicity for the drivers.

The goal was never to make event sourcing popular.

The goal is to make it boring.

When event sourcing stops being special, it will finally be everywhere it belongs.