Skip to content

What's New

Welcoming Nimbus: Event-Driven Development for TypeScript

Today we're thrilled to celebrate the launch of Nimbus, a new event-driven application framework for TypeScript built by our friends at Overlap in Vienna, Austria. Nimbus integrates natively with EventSourcingDB and brings clear, explicit support for commands, events, and queries to the JavaScript and TypeScript world. We're genuinely grateful to be celebrating this with them. Overlap has built something thoughtful and substantial, and the JavaScript and TypeScript world is better for it.

We won't pretend Nimbus is the first attempt to bring CQRS and Event Sourcing into JavaScript. There have been several over the years, including our own historical effort, wolkenkit. What makes Nimbus stand out is not novelty, but approach: a deliberately minimalist, explicit design built from day one around a dedicated event store. It's also a sign of something larger, a quiet but unmistakable shift in how serious teams are choosing to build software.

Email Uniqueness in Event Sourcing

Recently, a reader asked us how to enforce email uniqueness when registering users in an event-sourced system. It is a fair question. In a relational database, you add a column, slap on UNIQUE, and the problem is solved. The database does the heavy lifting, and you move on with your day. In Event Sourcing, that easy answer simply does not exist.

The good news is there are several reasonable ways to solve it. The bad news is that none of them is free. Each one pays for uniqueness somewhere, whether in scale, in latency, in user experience, or in operational complexity. Choosing among them is not a technical question. It is a question about what your business actually means by "unique."

Great Minds Should Not Think Alike, They Should Think Together

The Event Sourcing, Domain-Driven Design, and CQRS community is full of brilliant people. Thoughtful practitioners, passionate speakers, prolific authors. People who genuinely care about building better software through deeper domain understanding. And yet, for a community built around the idea of shared understanding, we have a remarkably hard time understanding each other.

The irony is hard to miss. We preach Ubiquitous Language as a cornerstone of Domain-Driven Design, insisting that teams must develop a precise, shared vocabulary for their domain. But when it comes to our own discipline, we can't even agree on what to call the things we work with every day. And that's just the beginning.

It's None of Your Business

Three weeks ago, we introduced Simple Mode, a new mode for EventSourcingDB that replaced expressive domain events with three universal operations: row-inserted, row-updated, and row-deleted. Many of you laughed. Some of you forwarded it to colleagues who were not sure whether to laugh or cry. But beneath the satire, the frustrations we exaggerated were real. Teams genuinely struggle with Event Sourcing, and the reason they give is almost always the same: "It's too complex. We just want to store data."

We have heard that sentence dozens of times. And every time, we have come to the same conclusion: the complexity is not the problem. The problem is a misunderstanding about whose job it is to make business decisions. Because right now, in codebases all over the world, developers are making those decisions every single day, quietly, implicitly, and almost always without realizing it. And that is where things go wrong.

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.