Skip to content

2026

Sagas vs Process Managers

The moment a workflow spans more than one aggregate or service, someone will say: "We need a saga." It has become the default term for anything that coordinates multiple steps in an event-driven system. Book a flight, reserve a hotel, charge the credit card, and if any step fails, roll everything back. That's a saga, right?

Not quite. What most people describe when they say "saga" is actually a different pattern with a different name, different responsibilities, and different trade-offs. The confusion is not just semantic. It leads to architectural decisions based on the wrong mental model, and those decisions are surprisingly hard to reverse.

Blueprinting the System: An Interview on Event Modeling

Golo: Adam, you created Event Modeling and have been teaching and refining it for years now. You are also the founder of AdapTech Group and have worked with countless teams on adopting this approach. Before we dive into the method itself, can you tell a little about what problem you were originally trying to solve? Was there a specific frustration with existing approaches that led you to develop something new?

Elixir Client SDK 1.0 Now Available

Today we're excited to announce the release of the official Elixir Client SDK for EventSourcingDB, version 1.0. If you're building event-sourced systems on the BEAM, you now have first-class support for writing, reading, and observing events from your Elixir applications.

Elixir has earned its place as one of the most compelling platforms for building fault-tolerant, distributed systems. With this SDK, we're bringing EventSourcingDB into that world, and we've made sure it feels like Elixir from the ground up.

REST in Peace

REST has become the de-facto standard for building web APIs. Almost every tutorial, framework, and job listing treats it as the obvious choice. But what most developers call "REST" has very little to do with what Roy Fielding described in his dissertation back in 2000. Today, REST typically means HTTP verbs, JSON payloads, and CRUD operations mapped to resources. And that is exactly where the problem begins.

Because once you strip away the buzzword, what remains is a thin wrapper around database operations, exposed over HTTP. We have spent years criticizing CRUD on the data level. It is time to look at what CRUD does to our APIs.

Hidden in Plain Sight: The Events You Forgot to Model

There's a very specific moment that most teams working with Event Sourcing eventually run into. Someone asks a seemingly simple question about the past: why did this happen, how often has that occurred, what would have been the case if things had gone differently. You open the event store, expecting the answer to be right there, because that's the promise, after all. The full history, nothing lost, everything reconstructible. And then you realize the event you'd need was never written. The information existed once, for a brief moment, and slipped away before anyone thought to catch it.

It's tempting to treat this as a checklist problem. Just write down the events you tend to forget, keep the list handy, refer to it during the next Event Storming. But that approach misses something important. The problem isn't that teams are lazy or careless. It's that the way we're taught to think about events quietly steers us away from certain kinds of events in the first place. If you want to stop forgetting them, it helps to understand why they vanish from the model to begin with.

A Skill for Easter: Teaching Claude to Speak EventSourcingDB

Two weeks ago, we introduced the MCP Server 1.0 for EventSourcingDB, connecting AI agents to your event store through the Model Context Protocol. It showed what becomes possible when LLMs can query events, inspect subjects, and run EventQL in natural language. But setting up a Docker container and configuring an MCP client is not always what you want when you just need to quickly interact with your database. Sometimes you want something lighter.

As a small Easter gift, we are releasing a Claude Code Plugin for EventSourcingDB. It is a set of Skills that teach Claude how to use the entire EventSourcingDB API. No SDK installation, no Docker container, no MCP configuration. You install the plugin, and start talking to your event store. Think of it as the lightest possible bridge between natural language and your events.

Introducing Simple Mode

Over the past few months, we have received more feedback than ever before. Hundreds of conversations with developers, architects, and CTOs have painted a remarkably consistent picture. The message was clear, and we owe it to you to be honest about what we heard: Event Sourcing is too complex. Not in theory. In theory, everyone loves it. But in practice, teams struggle. They struggle with modeling, with naming, with the sheer cognitive overhead of thinking in events rather than rows.

Debugging Event-Sourced Systems: A Detective's Guide

In a traditional CRUD system, debugging starts with a familiar question: "What is the current state?" You open the database, look at the row, and see that the order status is "cancelled." But you do not know why. Was it the customer? The payment provider? An automated process? The database shows you the crime scene, but not the crime. All you have is a body and no witnesses.

Event-sourced systems turn this on its head. Instead of inspecting the current state and guessing what went wrong, you follow the trail of events. Every change that ever happened is recorded, timestamped, and preserved. Debugging becomes less about guessing and more about reading. You are not a detective arriving at a cold case. You have a complete surveillance tape.

Introducing DDD to Your Organization

You have read the books. You have watched the talks. You are convinced that Domain-Driven Design would help your team build better software. The models would be clearer, the communication with stakeholders sharper, the architecture more aligned with the business. There is just one problem: nobody else in your organization knows what DDD is, and nobody asked for it.

Introducing DDD is not a technical challenge. It is a cultural one. You cannot install it like a library or deploy it like a service. It requires changing how people think about software, how they talk about problems, and how they collaborate across disciplines. That takes time, patience, and a strategy that goes beyond "let me show you this cool pattern."

Naming Events Beyond CRUD

You open the event store and see UserUpdated. What happened? Did the user change their email? Did they accept the terms of service? Did an admin reset their password? The event name tells you nothing. It is CRUD in disguise, a technical label that hides what actually occurred.

Now consider OrderDeleted. Why was it deleted? Did the customer cancel? Did the seller reject it? Was it flagged for fraud? Behind the same technical verb lie completely different business realities, each with its own consequences, its own rules, its own downstream effects. The name you give an event determines whether your system tells a story or keeps a secret.