Publishing Events

Once an event is stored, it doesn't just sit there – it needs to be published.

Publishing means making the event available to other parts of the system, so they can react to it. This is what turns an event-driven system from passive storage into active behavior.

In Our Library

Let's say a BookBorrowed event was just stored.

Now we want to:

• Update the member's list of active loans
• Mark the copy as unavailable
• Maybe send a confirmation email

Each of these actions happens in response to the event – but they happen outside the command handler.

Why Separation Matters

Publishing separates decision from reaction:

• The command handler decides what happened.
• Other components decide how to respond.

This makes the system loosely coupled: you can add new reactions (like notifications or analytics) without touching the core business logic.

Publishing Must Be Reliable

It's critical that events are not only stored, but also safely published. If you store an event but fail to publish it, parts of your system may never react.

Some systems solve this using patterns like the Transactional Outbox. Others – like systems based on EventSourcingDB – provide publishing as an integrated part of the storage process.

What matters is:

Storing and publishing must succeed together – or fail together.

Next up: Projections – learn how events are used to build queryable state.