DEV Community: kairi

【Event Sourcing】Trying Sekiban DCB: Implementing a Materialized View

kairi — Fri, 18 Sep 2026 07:06:28 +0000

In this article, we will use the student enrollment management system created in a previous article to explore how Materialized Views work and how to implement them.

kairi

Sep 16

[Event Sourcing] Trying out Sekiban DCB: Implementation

#eventsourcing #tutorial #dcb

6 min read

In this system, actions such as creating a student, updating a profile, and enrolling in a class are stored as events. We will create read-side tables from these events so that we can retrieve an enrollment list containing student names and class names using SQL.

A Materialized View (MV) stores read-side data calculated from the original data. In this implementation, Sekiban reads events and reflects them in SQL tables.

The stack used in this article is .NET 10 / Sekiban DCB 10.19.0 / Orleans / PostgreSQL. The code examples include only the parts needed for the explanation.

Why Use a Materialized View?

The event store contains events such as "a student was created" and "a student enrolled in a class." However, what we want to retrieve in an enrollment list is data that combines student names and class names.

Student Name	Class Name
Alice	Math
Alice	English
Bob	Math

One option is to retrieve the student list and class list separately and match them in the application. However, if the MV contains tables for students, classes, and enrollments, we can retrieve the required data with SQL JOINs.

Enrollment JOIN Student JOIN Class
  → Filter by conditions
  → Return an enrollment list containing student and class names

The role of the MV is to provide a data structure optimized for reading, separately from the format used to store events. Filtering and aggregation can also be written directly in SQL.

Overall Architecture

In this system, we use one database for events and another for the MV.

flowchart TD
    A[Create student / Update profile / Enroll in class] --> B[Validate business rules in the command]
    B --> C[(Event Store)]
    C --> D[Successful command response]
    C --> E[Sekiban MV Runtime]
    E --> F[Projector<br/>Convert events into SQL]
    F --> G[(MV Database<br/>Student / Class / Enrollment tables)]
    H[Enrollment List API] --> I[Get the currently active MV tables<br/>JOIN them with SQL]
    G --> I
    I --> J[Enrollment list containing student and class names]

The event store keeps the event history, while the MV database stores read-side data built from that history.

For example, when a student's name is updated, the process works as follows:

The command validates the requested change.
A StudentProfileUpdated event is stored.
The MV runtime reads the event.
The student table is updated using SQL generated by the Projector.
The enrollment list API returns the updated student name.

Event persistence and MV updates are separate processes, so there is a delay between a successful command response and the update becoming visible in the MV.

MV synchronization may complete within a few seconds, but when there are many events, it may take several minutes or longer. Because of this behavior, the MV should not be used to validate consistency or enforce business rules.

To guarantee consistency when writing data, retrieve the current state for each tag (aggregate) and perform validation on the command side.

The events remain the source of truth. The MV should be treated as read-side data that can be rebuilt from those events.

In this article, the MV is implemented as a set of read-side tables that are updated based on events.

Packages and Database Connections

The EventSource project, which contains the MV definitions, references Sekiban.Dcb.MaterializedView.

The API host also uses packages for PostgreSQL and Orleans integration.

According to the official Sekiban documentation, providers are available not only for PostgreSQL but also for databases such as SQL Server, MySQL, and SQLite.

<PackageReference Include="Sekiban.Dcb.MaterializedView" Version="10.19.0" />
<PackageReference Include="Sekiban.Dcb.MaterializedView.Postgres" Version="10.19.0" />
<PackageReference Include="Sekiban.Dcb.MaterializedView.Orleans" Version="10.19.0" />

This is the same configuration used in the existing sample.

Dapper is used to execute SQL and map query results to objects.

In AppHost, the MV database is passed to the API.

var materializedViewPostgres = postgresServer
    .AddDatabase("DcbMaterializedViewPostgres");

apiService = apiService
    .WithReference(materializedViewPostgres)
    .WaitFor(materializedViewPostgres);

In this sample, the same PostgreSQL server contains two databases: DcbPostgres for storing events and DcbMaterializedViewPostgres for storing the MV.

Implementing the Projector

The system already had an MV implementation. I added support for the StudentProfileUpdated event so that changes to a student's name and enrollment limit are also reflected in the read-side tables.

A Projector is a class that converts events into read-side data.

In this example, ClassRoomEnrollmentMvV2 implements IMaterializedViewProjector.

public sealed class ClassRoomEnrollmentMvV2 : IMaterializedViewProjector
{
    public string ViewName => "ClassRoomEnrollment";
    public int ViewVersion => 2;

    // Implement InitializeAsync and ApplyToViewAsync.
}

The two main methods are:

Method	Role
`InitializeAsync`	Registers and creates the MV tables
`ApplyToViewAsync`	Generates SQL for each event

Defining the Tables

The enrollment list uses the following three tables.

Table	Main Data
`students`	Student ID, name, enrollment limit, number of enrollments
`classrooms`	Class ID, name, capacity, number of enrolled students
`enrollments`	Student ID, class ID, enrollment date and time

In InitializeAsync, we register a logical table name and then create the table using the physical name provided by the runtime.

Students = ctx.RegisterTable(StudentsLogicalTable);

The following is an excerpt from the DDL for the student table.

{Students.PhysicalName} is the table name inserted by C# string interpolation.

CREATE TABLE IF NOT EXISTS {Students.PhysicalName} (
    student_id UUID PRIMARY KEY,
    name TEXT NOT NULL,
    max_class_count INT NOT NULL,
    enrolled_count INT NOT NULL DEFAULT 0,
    _last_sortable_unique_id TEXT NOT NULL,
    _last_applied_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

This DDL is executed with ctx.ExecuteAsync.

By obtaining the physical table name from the runtime instead of hard-coding it, we can work with tables that correspond to different MV versions.

Returning SQL for Each Event

In ApplyToViewAsync, the logic is selected according to the event type, and a list of MvSqlStatement objects is returned.

The student-related part looks like this:

StudentCreated created =>
    [InsertStudent(created, ctx.CurrentSortableUniqueId)],
StudentProfileUpdated updated =>
    [UpdateStudent(updated, ctx.CurrentSortableUniqueId)],

The relationship between events and MV updates is as follows:

Event	Update to the MV
`StudentCreated`	Insert a student
`ClassRoomCreated`	Insert a class
`StudentProfileUpdated`	Update the student's name and enrollment limit
`StudentEnrolledInClassRoom`	Insert an enrollment and update enrollment counts for the student and class
`StudentDroppedFromClassRoom`	Delete an enrollment and update enrollment counts for the student and class

Business rules, such as the enrollment limit, are validated on the command side.

The Projector converts stored events into SQL, and the MV runtime applies that SQL.

Reflecting Profile Updates

When a profile is updated, the student's name and enrollment limit are changed.

UPDATE {Students.PhysicalName}
SET name = @Name,
    max_class_count = @MaxClassCount,
    _last_sortable_unique_id = @SortableUniqueId,
    _last_applied_at = NOW()
WHERE student_id = @StudentId
  AND _last_sortable_unique_id < @SortableUniqueId;

The values are passed as SQL parameters.

This update does not modify the enrollment count or enrollment records, so the existing enrollment information is preserved even when the student's name changes.

_last_sortable_unique_id represents the position of the latest event applied to the row.

The update is performed only when the incoming event is newer. This condition helps prevent duplicate processing and older events from overwriting newer data, while assuming that the MV runtime applies events in order.

Registering the MV Runtime

In the API's Program.cs, we register the Projector and the MV storage.

The following is an excerpt from the registration code:

builder.Services.AddSekibanDcbMaterializedView(options =>
{
    options.AllowDefaultServiceId = true;
    options.BatchSize = 100;
    options.PollInterval = TimeSpan.FromSeconds(1);
});

builder.Services.AddMaterializedView<ClassRoomEnrollmentMvV2>();

builder.Services.AddSekibanDcbMaterializedViewPostgres(
    builder.Configuration,
    connectionStringName: "DcbMaterializedViewPostgres",
    registerHostedWorker: false);

builder.Services.AddSekibanDcbMaterializedViewOrleans();

In this example, Orleans manages MV processing, so registerHostedWorker is set to false.

AllowDefaultServiceId is configured for the single-service setup used in this sample.

Retrieving the Enrollment List from the MV

On the read side, IMvOrleansQueryAccessor is used to obtain the database connection information and table definitions.

var context = await mvQueryAccessor.GetAsync(
    projector, cancellationToken: cancellationToken);

var studentsTable = context.GetRequiredTable(
    ClassRoomEnrollmentMvV2.StudentsLogicalTable);

The class and enrollment tables are retrieved in the same way.

The main part of the SQL query uses the physical table names to perform JOINs:

var sql = $"""
    SELECT e.student_id AS "StudentId", s.name AS "StudentName",
           e.class_room_id AS "ClassRoomId", c.name AS "ClassName",
           e.enrolled_at AS "EnrolledAt",
           e._last_sortable_unique_id AS "LastSortableUniqueId"
    FROM {enrollmentsTable.PhysicalTable} e
    INNER JOIN {studentsTable.PhysicalTable} s
        ON s.student_id = e.student_id
    INNER JOIN {classRoomsTable.PhysicalTable} c
        ON c.class_room_id = e.class_room_id
    """;

The actual implementation also adds filtering by student ID and class ID, as well as sorting.

Dapper maps the result to the response type.

var rows = (await connection.QueryAsync<EnrollmentListMvItem>(
    new CommandDefinition(
        sql,
        parameters,
        cancellationToken: cancellationToken))).ToList();

connection is an Npgsql connection to the MV database, and parameters contains the filter conditions.

The endpoint is:

GET /api/mv/enrollments/

Because the result already contains both the student name and class name, the caller does not need to retrieve separate lists and match them manually.

Waiting for the MV After an Update

If we query the MV immediately after an update, it may still return the previous data.

In this sample, the command API returns a sortableUniqueId. By passing this value to the query API, we can wait until the MV has processed events up to that position.

Update the profile
  → Get sortableUniqueId from the response
  → Pass it to the enrollment API as waitForSortableUniqueId
  → Wait until the MV reaches that event position
  → Retrieve the data

The waiting logic checks the processing position with the following call:

await context.Grain.IsSortableUniqueIdReceived(sortableUniqueId);

The implementation also handles timeouts and cancellation.

What we are waiting for here is the event processing position. Therefore, if the Projector does not contain logic for the profile update event, waiting for the event to be processed will not update the student's name.

Managing Versions with ViewVersion

An MV has its own read-model version, separate from the Sekiban package version.

public string ViewName => "ClassRoomEnrollment";
public int ViewVersion => 2;

Property	Meaning
`ViewName`	Name of the read model
`ViewVersion`	Version of the table structure and projection logic

The existing version 1 did not process StudentProfileUpdated.

If events have already been processed without handling this event, simply adding the new logic does not automatically cause previously processed events to be read again.

Version 1
  Student created       → Insert student
  Profile updated       → Skip without processing
  Student enrolled      → Insert enrollment

Version 2
  Student created       → Insert student
  Profile updated       → Update name and enrollment limit
  Student enrolled      → Insert enrollment

For this reason, after adding support for StudentProfileUpdated, I changed ViewVersion to 2.

This allows the MV to be rebuilt from historical events using the new projection logic.

Even if the table columns do not change, changing the version is useful when the data produced from historical events changes.

On the other hand, if we only add more fields to a query by JOINing existing tables, rebuilding the MV is usually unnecessary.

Getting the Currently Active MV Tables

Because the tables are separated by version, the API needs to determine which version is currently active.

This is handled by IMvOrleansQueryAccessor.

Use version 1
  → Build the data for version 2
  → Once version 2 is ready, switch queries to version 2

By obtaining the table names through the Accessor instead of hard-coding physical table names in the API, the query destination can be switched between versions.

It is not enough to rename the class to V2. ViewVersion and the registered Projector must also be updated together.

Verifying the API Behavior

First, create a student named "Alice" and a class named "Math", enroll Alice in the class, and retrieve the enrollment list.

Then change the student's name to "Alice Updated", wait for the update event to be reflected in the MV, and retrieve the list again.

Item	Before Update	After Update
Student name	Alice	Alice Updated
Class name	Math	Math
Enrollment	Alice is enrolled in Math	The same enrollment is preserved

If we get this result, we can confirm that the profile update has been reflected in the student table and that the updated name is also used in the enrollment list generated through the JOIN.

When the student drops the class, we also verify that the corresponding enrollment disappears from the list and that the enrollment counts for both the student and class are updated.

Verification Results

Using the actual API, Orleans, and PostgreSQL, I verified the following behavior:

Updates to the student's name and enrollment limit were reflected in the MV, and the updated name appeared in the joined enrollment list.
The existing enrollment information and enrollment timestamp were preserved after the profile update, and additional enrollments were reflected correctly.
Updates that violated business rules were rejected, and the MV was not changed.
Filtering by student and class, as well as dropping an enrollment, was reflected correctly in the query results.
After restarting with version 2 instead of version 1, historical profile updates were reflected, and the API also switched its query target to version 2.
I re-projected 13 events into an empty MV database and confirmed that the student names, enrollment limits, enrollment relationships, and counts matched the data before the rebuild. The original events were not modified.

Summary

In this article, we used Sekiban DCB's Materialized View functionality to build an enrollment list that can be queried with SQL from stored events.

In addition to reflecting updates, we also confirmed version switching and rebuilding the MV from historical events.

Materialized Views are useful when you want to join or aggregate multiple pieces of information with SQL, or when you want to expose read-side data as database tables.

A good place to start is a familiar list endpoint like this one. Try updating tables from events and see how the read model changes as new events are processed.

References

[Event Sourcing] Building an Application Fast Using the Event Sourcing Pattern with Sekiban DCB and AI

kairi — Thu, 17 Sep 2026 08:15:43 +0000

1. Introduction

In this article, we will build an event-sourced application using Sekiban DCB and AI. Along with implementing the UI and APIs, we will check whether the application maintains consistency when multiple operations happen at the same time.

For this project, I used Codex × GPT-6 Astra.

The Sekiban DCB Decider template includes sample implementations that we can use as references when giving instructions to AI.

These samples cover the full flow from the UI to APIs, business rules, and event persistence. We will explore how far we can take feature development and verification with AI by following these existing implementations.

As an example, we will build a simple library management application that supports registering, borrowing, and returning books. We will use PostgreSQL for storage and create a basic Blazor UI to try out the APIs.

The sample code is available here:
BookManagement sample on GitHub

2. Creating a Project from the Template

First, run the following commands to create a project from the template:

dotnet new install Sekiban.Dcb.Templates
dotnet new sekiban-dcb-decider -n BookManagement

You can also find instructions for getting started with the Decider template in the Quick Start on the official website.

For this project, I used the .NET 10 SDK and Linux containers in Docker Desktop. The UI was built with Blazor.

The generated project already included samples for Student, ClassRoom, and Enrollment:

Student: Students and their enrollment limits
ClassRoom: Classes and their capacity
Enrollment: Enrolling in and withdrawing from classes

We will ask AI to implement new features using these samples as references.

3. Implementing the Features

The detailed business requirements, consistency rules, and verification scenarios are available in docs/spec.md in the sample code. Below is an excerpt from the instructions I gave AI to keep the implementation consistent with the existing samples:

Before you start implementing, read the existing Student, ClassRoom, and
Enrollment implementations from end to end, including the UI, APIs,
commands, Deciders, events, states, and queries.

Treat these implementations as the standard for this project.
Rather than introducing a new design or coding style, implement the
library management features by adapting similar existing code.

If the existing code uses multiple approaches, choose the one closest
to the business operation you are adding.
Do not introduce custom helpers, new abstractions, or shorthand syntax.
Only if the existing approach cannot meet the requirements, explain why,
propose a change, and ask for confirmation before proceeding.

The entire implementation took less than an hour, including reviewing the existing code, implementing the features, building the project, running integration and concurrency tests against a real PostgreSQL database, and checking and fixing the UI.

Implementing Business Rules with the Decider Pattern

In this template, business rules live in Deciders associated with events and states. Their main responsibilities are Validate, which checks whether an operation is allowed, and Evolve, which applies an event to a state.

Below is an excerpt from the borrowing logic we implemented. Book represents the book being borrowed, User represents the borrower, and Loan represents a single loan. If the book is already on loan, another borrowing attempt is rejected. When the borrowing event is applied, the resulting state stores the LoanId and UserId.

public static class BookBorrowedDecider
{
    public static void Validate(this BorrowedBookState state)
    {
        throw new InvalidOperationException(
            $"Book {state.BookId} is already borrowed");
    }

    public static BorrowedBookState Evolve(
        this AvailableBookState state, BookBorrowed borrowed) =>
        new(state.BookId, state.Name, borrowed.LoanId, borrowed.UserId);
}

The Handler coordinates state retrieval and validation, then returns an event if validation succeeds. The Decider itself does not need any code for connecting to PostgreSQL.

flowchart LR
    UI[Blazor UI] --> API[API]
    API --> H[Command Handler]
    H --> V[State retrieval and Decider validation]
    V --> E[Event creation]
    E --> S[Conflict detection and persistence by Sekiban]
    S --> P[Projector / List projection]
    P --> Q[Query]
    Q --> UI

In this project, AI implemented the new business rules using the same Decider structure as the existing code. Keeping the code structure consistent as features are added also makes it easier for developers to know where to look for business rules. This is where I found the approach particularly useful for AI-assisted coding.

Maintaining Consistency Across Multiple Entities with DCB

Checking the current state alone does not solve concurrency problems. Two requests can read the same state before either updates it, and both can conclude that the operation is allowed.

For example, if two users try to borrow the same book at almost the same time, both requests might read its status as “available” before it changes. Similarly, if one user borrows different books at the same time, each request might appear to be within the borrowing limit, while the combined result exceeds it.

This is where DCB, or Dynamic Consistency Boundary, comes in. It uses tags to define which entities must remain consistent together for a particular operation. Sekiban DCB provides optimistic concurrency control based on these tags.

Our borrowing event has the following structure:

public record BookBorrowed(
    Guid LoanId,
    Guid BookId,
    Guid UserId,
    DateTime BorrowedAt) : IEventPayload
{
    public EventPayloadWithTags GetEventWithTags() =>
        new(this,
            new LoanTag(LoanId),
            new BookTag(BookId),
            new UserTag(UserId));
}

We attach three tags—Loan, Book, and User—to a single fact: a book was borrowed. Each is defined as a consistency tag, and the Handler reads and validates the corresponding state.

Entity to check	Rule to enforce
Book	Prevent the same book from being loaned out twice at the same time
User	Keep the user within the borrowing limit, even when requests involve different books
Loan	Identify each loan and check for duplicates and whether it has been returned

Sekiban handles the concurrency checks that determine whether the events can be saved based on the state we read. The application returns an error for a request that encounters a conflict.

The key is deciding which business conditions to validate and which entities to include in the consistency boundary. Adding tags alone does not automatically enforce arbitrary business rules. We define those rules explicitly in the Deciders and Handlers, then let the framework detect conflicts when saving events.

A Blazor UI for Trying Out the APIs

The UI is a simple interface for trying out the APIs. The screenshots below show it with sample data prepared for this article (The UI was originally built in Japanese. The screenshots below have been edited to show the labels and sample data in English for this article.).

The book list shows each book’s status. The button for removing a book from the catalog is disabled while the book is on loan.

On the borrowing and returns screen, you can select a user and a book to create a loan. Loan records remain in the history after the books are returned, and the Return button is disabled for those records. The API’s business rules also check whether each operation is allowed.

To verify that consistency was maintained, we tested the following scenarios:

Concurrent attempts to borrow the same book
The same user borrowing different books concurrently
Concurrent attempts to return the same Loan
Concurrent requests to create a new loan, return an already returned loan again, and remove the book from the catalog
For a book currently on loan, concurrent requests to return the current loan, create a new loan, and remove the book from the catalog

For every scenario, we sent multiple requests at almost the same time to an API connected to a real PostgreSQL database. We confirmed that operations violating the business rules were rejected and that the related states remained consistent.

4. Conclusion

By asking AI to add features that followed the existing samples, we were able to implement and verify the application in a short time. Letting Sekiban handle conflict detection and persistence also allowed us to focus on implementing the business rules.

I hope this article encourages you to try building an event-sourced application with Sekiban DCB and AI.

[Event Sourcing] Running an Existing C# Business Model on Wasm with SekibanWasmRuntime

kairi — Wed, 16 Sep 2026 06:05:09 +0000

In the previous article, we created a C# application using Sekiban DCB to handle students, classes, and class enrollment. This time, we will try running that application with SekibanWasmRuntime, which allows Sekiban to run with Wasm (WebAssembly).

In this article, we will run a project written in C# as Wasm. SekibanWasmRuntime currently provides primary support for C# and Rust, while Go, TypeScript, MoonBit, and Swift are also available as experimental implementations.

The sample code used in this article is available here.

1. Roles of Sekiban and Wasm

Sekiban is an event sourcing framework that provides a mechanism for storing events that occur in an application and building the current state from those events.

Wasm is an executable format produced by compiling code. In this example, SekibanWasmRuntime running on the server loads and executes the Wasm file. The application contains the business code related to students, while the Runtime provides the environment for executing that code and the mechanism for storing events.

2. What Runs in Wasm

The architecture used in this example is as follows.

Scalar / PowerShell
    ↓ 
API
    ↓ ISekibanExecutor
RemoteSekibanExecutor
    ├── Executes existing Command handlers on the API side
    └── Requests state retrieval, event commit, and Query execution over HTTP
            ↓ 
SekibanWasmRuntime
    ├── Executes the Projector and list Query in Wasm
    └── Stores events in PostgreSQL

Command handlers run on the API side, while the Projector that builds state from events and the student list processing run as Wasm inside the Runtime.

When a student is created, the process works in the following order.

The HTTP endpoint receives the request to create a student.
The existing Command handler runs on the API side and creates an event according to the business rules.
The API requests the Runtime to store the event through the Remote connection.
The Runtime stores the event, and the Projector in Wasm applies the event when state is retrieved or the list is updated.
The retrieval API can then be used to check the state of the created student or the student list.

The business logic remains unchanged, but we need to add an entry point for calling Wasm, type registration, and API connection settings. The entire Web API and all Commands do not run inside Wasm.

For this example, I used the following versions.

Component	Version
.NET	10
Sekiban.Dcb	10.19.0
Sekiban.Dcb.WasmRuntime.Aspire	1.0.0-preview.6
Sekiban.Dcb.WasmRuntime.Remote	1.0.0-preview.6
Runtime container	1.0.0-preview.3

The NuGet packages and the Runtime container use different version series.

3. What Was Added or Changed

To reuse the existing business logic, I added the Wasm entry point and execution environment.

The official C# Wasm template specifies using Docker when building Wasm on Windows or macOS. Following this procedure, we prepare the build environment for compiling C# to Wasm inside Docker. The generated Wasm file is then loaded and executed by SekibanWasmRuntime.

Added or changed item	Purpose
Wasm project	References the existing EventSource and builds it as Wasm
Wasm entry point and type registration	Connects the Runtime to the existing Projector and provides the type information required for ahead-of-time compilation
manifest	Tells the Runtime which Wasm, events, Projectors, and Queries are associated with each other
Build scripts	Build Wasm inside Docker
AppHost settings	Start the Runtime container and a dedicated PostgreSQL instance
Remote connection for the API	Replaces the `ISekibanExecutor` implementation with `RemoteSekibanExecutor`

The Wasm project references the existing code as follows. The following code snippets show the main settings and implementations that were added.

<ProjectReference Include="..\DCBNativeWasmProject.EventSource\DCBNativeWasmProject.EventSource.csproj" />

At the entry point called by the Runtime, we use the existing Projector.

instance.State = StudentProjector.Project(instance.State, ev);

On the API side, we register the implementation used to communicate with the Runtime.

builder.Services.AddHttpClient<RemoteSekibanExecutor>(http =>
{
    http.BaseAddress = new Uri(builder.Configuration["Runtime:BaseUrl"]!);
    http.Timeout = TimeSpan.FromSeconds(90);
});

builder.Services.AddTransient<ISekibanExecutor>(
    sp => sp.GetRequiredService<RemoteSekibanExecutor>());

With this configuration, the existing endpoints can continue calling executor.ExecuteAsync(command).

Package and Wasm Configuration

Run the following commands from the project root directory. Prepare the .NET 10 SDK and Docker Desktop beforehand. On Windows, use Git Bash, and on macOS, use a terminal. Because the build tools are provided inside Docker, you do not need to install the WASI SDK directly.

The packages added to AppHost and the API are as follows.

dotnet add ./DCBNativeWasmProject.AppHost\DCBNativeWasmProject.AppHost.csproj package Sekiban.Dcb.WasmRuntime.Aspire --version 1.0.0-preview.6
dotnet add ./DCBNativeWasmProject.ApiService\DCBNativeWasmProject.ApiService.csproj package Sekiban.Dcb.WasmRuntime.Remote --version 1.0.0-preview.6

The following settings are added to DCBNativeWasmProject.Wasm/DCBNativeWasmProject.Wasm.csproj to generate Wasm output. These are the main settings.

<TargetFramework>net10.0</TargetFramework>
<RuntimeIdentifier>wasi-wasm</RuntimeIdentifier>
<OutputType>library</OutputType>
<AllowUnsafeBlocks>true</AllowUnsafeBlocks>
<InvariantGlobalization>true</InvariantGlobalization>
<IsAotCompatible>true</IsAotCompatible>
<SelfContained>true</SelfContained>
<IlcExportUnmanagedEntrypoints>true</IlcExportUnmanagedEntrypoints>
<NativeLib>Shared</NativeLib>

The actual file also includes a package reference for NativeAOT-LLVM and linker settings that expose the functions called by the Runtime. In WasmExports.cs, type information is explicitly registered, and entry points are provided for applying events, saving and restoring state, and retrieving lists. NuGet.wasm.config specifies the package sources required for this build.

Map Wasm and Processing in the manifest

config/sekiban-manifest.json tells the Runtime which Projectors and Queries are provided by each Wasm module. The following is an excerpt related to the student list.

{
  "defaultModulePath": "/app/modules/dcb-native.wasm",
  "queryAssemblyVersion": "wasm",
  "projectors": [
    {
      "projectorName": "StudentListProjection",
      "projectorVersion": "1.0.1",
      "modulePath": "/app/modules/dcb-native.wasm",
      "abiKind": "wasi-preview1",
      "moduleVersion": "1.0.0"
    }
  ],
  "queryProjectors": {
    "GetStudentListQuery": "StudentListProjection"
  }
}

Connect the Runtime and API from AppHost

In DCBNativeWasmProject.AppHost/WasmAppHost.cs, we start the Runtime and a PostgreSQL instance. root is the absolute path to the project root.

var pg = builder.AddPostgres("wasm-postgres");
var events = pg.AddDatabase("SekibanDcb", "dcb_native_wasm_events");

var runtime = builder.AddSekibanWasmRuntime(
    "wasm-runtime",
    new SekibanWasmRuntimeOptions
    {
        ConfigDirectory = Path.Combine(root, "config"),
        ModulesDirectory = Path.Combine(root, "modules"),
        WasmModulePath = "/app/modules/dcb-native.wasm",
        EventStoreDatabase = events,
        ProjectionMode = "memory-only",
        HostPort = 5280
    })
    .WithEnvironment("SEKIBAN_WASM_POOL_SIZE", "0")
    .WaitFor(events);

memory-only is the projection mode used to build projections by applying events. The events themselves are stored in PostgreSQL. SEKIBAN_WASM_POOL_SIZE=0 is set as a workaround for an issue in this preview version where consecutive list updates could wait indefinitely. This is not a recommended value that has been evaluated for production use.

Next, we pass the Runtime URL to the API.

builder.AddProject<DCBNativeWasmProject_ApiService>(
        "wasm-api", launchProfileName: null)
    .WithEnvironment("Runtime__BaseUrl", runtime.GetEndpoint("http"))
    .WithEnvironment("ASPNETCORE_ENVIRONMENT", "Development")
    .WithHttpEndpoint(
        port: 5241, targetPort: 5241, name: "http", isProxied: false)
    .WithEnvironment("ASPNETCORE_URLS", "http://localhost:5241")
    .WaitFor(runtime);

Runtime__BaseUrl passes the SekibanWasmRuntime endpoint to the API. The API uses this endpoint to request state retrieval and event storage from the Runtime.

4. Build the Wasm File

Start Docker Desktop and move to the project root directory in your terminal. Adjust the path to match your working directory.

bash scripts/build-wasm.sh

The script uses scripts/Dockerfile.wasm-build to create a Docker image for the build, and then scripts/build-wasm-container.sh runs the following command inside the container.

dotnet publish DCBNativeWasmProject.Wasm/DCBNativeWasmProject.Wasm.csproj \
  -c Release -r wasi-wasm \
  -o artifacts/wasm/publish --configfile NuGet.wasm.config

The build result is copied to the location used by the Runtime, and wasm-tools validate is used to validate the Wasm format. When the build succeeds, a log similar to the following is displayed. The file size may change depending on the implementation.

Example output when the Wasm build completes:

[build-wasm] OK: modules/dcb-native.wasm (25282599 bytes)

Output Locations of the Build Files

The following paths are relative to the project root.

Location	Description
`artifacts/wasm/publish/DCBNativeWasmProject.Wasm.wasm`	Wasm generated by `publish`
`modules/dcb-native.wasm`	A copy of the generated Wasm file that is loaded by the Runtime
`DCBNativeWasmProject.Wasm/bin/` and `obj/`	Build outputs and intermediate files
`config/sekiban-manifest.json`	Runtime configuration created manually. This is not a build output.

The modules folder on the host is mounted into the Runtime container. Therefore, the manifest and AppHost specify /app/modules/dcb-native.wasm, which is the path inside the container.

The Wasm project used in this example is built separately from the normal solution build. Run the dedicated build script before starting AppHost.

5. Start the Application

In the same terminal, set the environment variables and start AppHost.

export ASPIRE_ALLOW_UNSECURED_TRANSPORT=true
export ASPNETCORE_URLS=http://localhost:15900
export ASPIRE_DASHBOARD_OTLP_ENDPOINT_URL=http://localhost:15901
export ASPIRE_DASHBOARD_OTLP_HTTP_ENDPOINT_URL=http://localhost:15902

dotnet run --project DCBNativeWasmProject.AppHost --no-launch-profile

These settings are for local execution. AppHost starts the dedicated PostgreSQL instance, the Runtime container, and the API.

6. Execution Results

Create a student from Scalar, and then retrieve the student using the same ID. The following is the actual response returned by the API for the request shown below. The IDs will be different each time you run it.

POST /api/students/
Content-Type: application/json

{
  "studentId": "10c8f945-8314-4631-8c3d-627dbd22934a",
  "name": "山田太郎",
  "maxClassCount": 5
}

{
  "studentId": "10c8f945-8314-4631-8c3d-627dbd22934a",
  "eventId": "01a08f5c-d51e-7cf9-9e22-ad1348d4137e",
  "sortableUniqueId": "063924708420894567502099121181",
  "message": "Student created successfully"
}

Next, retrieve the student that was created.

GET /api/students/10c8f945-8314-4631-8c3d-627dbd22934a

{
  "studentId": "10c8f945-8314-4631-8c3d-627dbd22934a",
  "payload": {
    "studentId": "10c8f945-8314-4631-8c3d-627dbd22934a",
    "name": "山田太郎",
    "maxClassCount": 5,
    "enrolledClassRoomIds": []
  },
  "version": 1
}

The student creation event is applied by the Projector running in Wasm, and we can retrieve the student's state. List retrieval and updates can also be executed from the same Scalar screen.

7. Conclusion

By using SekibanWasmRuntime, we can change the execution environment while continuing to use existing models and Projectors, as in this example, by adding a Wasm entry point and connection settings. The business logic we have already created can also be used with this architecture.

I also felt that by leaving event storage and Wasm execution to SekibanWasmRuntime, the application side can focus more on implementing the business logic: what kinds of operations the application accepts and what kinds of events those operations produce. Because the API can use the Runtime through a Remote connection, the part that calls the business processing can be separated from the part responsible for execution and storage.

Samples for Go and TypeScript are also available as experimental/reference implementations, and I am looking forward to seeing further support added in the future.

[Event Sourcing] Trying out Sekiban DCB: Implementation

kairi — Wed, 16 Sep 2026 04:50:24 +0000

Introduction

This article is a continuation of "[Event Sourcing] Trying out Sekiban DCB: Introduction". In the previous post, we covered setting up the DCB Native environment and its processing flow.

kairi

Sep 16

[Event Sourcing] Trying out Sekiban DCB: Introduction

#tutorial #eventsourcing #dcb

2 min read

Initially, features like creating a Student, fetching individual and list data, and enrolling/dropping classes are already implemented. The student's state is built from recorded events. The information a student holds includes Student ID, Name, Max Class Count, and a list of currently enrolled classes.

In this post, we will add a feature to update a student's name and their maximum class limit. The Student ID and enrolled classes will remain unchanged. Decreasing the max limit below the current number of enrolled classes will be prohibited.

When updating, we don't directly overwrite the current data. Instead, we record a StudentProfileUpdated event. A Projector then processes this event to build the updated student state.

Update Feature Specifications

Item	Specification
`StudentId`	Specifies the student to update. It is not changed.
`Name`	Required, 1 to 100 characters
`MaxClassCount`	1 to 10. Changing it to a value lower than the current enrollment count is not allowed.
Enrollment list	Keeps the contents before the update.
Non-existing student	The update is rejected.

The API receives JSON containing the student ID.

POST /api/students/update
Content-Type: application/json

{
  "studentId": "9912a519-a6f6-41fe-92bf-07b99045efff",
  "name": "John",
  "maxClassCount": 3
}

We will add the implementation in the order of Event, Decider, Command, Projector, and API.

The sample code is available on GitHub.

1. Add an Event That Represents the Update

We define the fact that the student information was updated as StudentProfileUpdated event.

using Dcb.ImmutableModels.Tags;
using Sekiban.Dcb.Events;

namespace Dcb.ImmutableModels.Events.Student;

public record StudentProfileUpdated(
    Guid StudentId,
    string Name,
    int MaxClassCount) : IEventPayload
{
    public EventPayloadWithTags GetEventWithTags() =>
        new(this, new StudentTag(StudentId));
}

The event records the target student ID, the updated name, and the updated maximum number of classes. By adding StudentTag, this event is associated with the target student.

The enrollment list is not included in the event because it is not part of this update.

2. Implement Business Rules and State Updates in Deciders

In Deciders, we implement validation based on the current state and the processing that applies the event to the state.

using Dcb.ImmutableModels.Events.Student;

namespace Dcb.ImmutableModels.States.Student.Deciders;

public static class StudentProfileUpdatedDecider
{
    public static void Validate(StudentState state, int maxClassCount)
    {
        if (maxClassCount < state.EnrolledClassRoomIds.Count)
        {
            throw new ApplicationException(
                "MaxClassCount cannot be less than the current enrollment count.");
        }
    }

    public static StudentState Evolve(
        this StudentState state,
        StudentProfileUpdated updated) =>
        state with
        {
            Name = updated.Name,
            MaxClassCount = updated.MaxClassCount
        };
}

In Validate, the updated maximum class count is compared with the current number of enrolled classes. For example, if a student is enrolled in three classes, the maximum class count cannot be changed to two.

In Evolve, the state with the contents of the event applied is returned. Only the name and maximum class count can be changed, while the student ID and enrollment list are kept unchanged.

3. Add a Command to Handle Update Requests

UpdateStudent is responsible for defining the input values and handling the processing from retrieving the state to generating the event.

using System.ComponentModel.DataAnnotations;
using Dcb.ImmutableModels.Events.Student;
using Dcb.ImmutableModels.States.Student;
using Dcb.ImmutableModels.States.Student.Deciders;
using Dcb.ImmutableModels.Tags;
using Sekiban.Dcb.Commands;
using Sekiban.Dcb.Events;

namespace Dcb.EventSource.Student;

public record UpdateStudent : ICommandWithHandler<UpdateStudent>
{
    public Guid StudentId { get; init; }

    [Required(ErrorMessage = "Name is required")]
    [StringLength(
        100,
        MinimumLength = 1,
        ErrorMessage = "Name must be between 1 and 100 characters")]
    public string Name { get; init; }

    [Range(1, 10,
        ErrorMessage = "MaxClassCount must be between 1 and 10")]
    public int MaxClassCount { get; init; }

    public UpdateStudent(
        Guid studentId,
        string name,
        int maxClassCount)
    {
        StudentId = studentId;
        Name = name;
        MaxClassCount = maxClassCount;
    }

    public static async Task<EventOrNone> HandleAsync(
        UpdateStudent command,
        ICommandContext context)
    {
        var tag = new StudentTag(command.StudentId);

        var tagState =
            await context.GetStateAsync<StudentProjector>(tag);

        if (tagState.Payload is not StudentState state)
        {
            throw new ApplicationException("Student does not exist.");
        }

        StudentProfileUpdatedDecider.Validate(
            state,
            command.MaxClassCount);

        return new StudentProfileUpdated(
            command.StudentId,
            command.Name,
            command.MaxClassCount)
            .GetEventWithTags();
    }
}

Validation	Implementation location
Name is required and has a valid length	Command attributes
Maximum class count is between 1 and 10	Command attributes
The student to update exists	Command handler
Maximum class count is greater than or equal to the current enrollment count	Decider

After Sekiban validates the Command attributes, the handler retrieves the current state of the student. If the business rule validation passes, it generates and returns StudentProfileUpdated.

Sekiban handles event persistence, so there is no need to write database persistence logic in the handler.

4. Add Update Event Handling to the Projector

Saving the event alone does not reflect the update in the student state. We add handling for the update event and Evolve to the Projector that builds the state.

For StudentProjector, which handles the state of a single student, add the following branch.

(StudentState state, StudentProfileUpdated updated)
    => state.Evolve(updated),

The processing for each event becomes as follows.

public static ITagStatePayload Project(
    ITagStatePayload current,
    Event ev) =>
    (current, ev.Payload) switch
    {
        (EmptyTagStatePayload, StudentCreated created)
            => StudentCreatedDecider.Create(created),
        (StudentState state, StudentProfileUpdated updated)
            => state.Evolve(updated),
        (StudentState state, StudentEnrolledInClassRoom enrolled)
            => state.Evolve(enrolled),
        (StudentState state, StudentDroppedFromClassRoom dropped)
            => state.Evolve(dropped),
        _ => current
    };

We also add handling for the same event to StudentListProjection, which builds the student list.

var newState = ev.Payload switch
{
    StudentCreated created
        => StudentCreatedDecider.Create(created),
    StudentProfileUpdated updated
        => currentState.Evolve(updated),
    StudentEnrolledInClassRoom enrolled
        => currentState.Evolve(enrolled),
    StudentDroppedFromClassRoom dropped
        => currentState.Evolve(dropped),
    _ => currentState
};

With this, the updated name and maximum class count are reflected in both the state of a single student and the student list.

5. Add the Update API

Add an endpoint to StudentEndpoints that receives the update Command.

group.MapPost("/update", UpdateStudentAsync)
    .WithName("UpdateStudent");

private static async Task<IResult> UpdateStudentAsync(
    [FromBody] UpdateStudent command,
    [FromServices] ISekibanExecutor executor)
{
    var execution = await executor.ExecuteAsync(command);

    return Results.Ok(new
    {
        studentId = command.StudentId,
        eventId = execution.EventId,
        sortableUniqueId = execution.SortableUniqueId,
        message = "Student updated successfully"
    });
}

The API directly receives UpdateStudent and asks Sekiban to execute it. The check for whether the student exists and the validation of the maximum class count are handled through the Command and Decider processing.

The flow from the update request to event persistence is as follows.

POST /api/students/update
    ↓
UpdateStudent
    ↓
Validate input values
    ↓
Retrieve the current student state
    ↓
Check the existence of the student
and the consistency of the maximum class count
    ↓
Generate StudentProfileUpdated
    ↓
Sekiban stores the event

When building or updating the state from the stored event, the Projector calls the corresponding Evolve.

Events Stored in PostgreSQL

Let's check the events actually stored in the database. In dcb_events, the following creation event and update event are stored. The data below was retrieved in ascending order of SortableUniqueId.

[
  {
    "ServiceId": "default",
    "Id": "01a0840a-df7f-7c43-9665-0564c61c7718",
    "SortableUniqueId": "063924518500223460000021724853",
    "EventType": "StudentCreated",
    "Payload": {
      "studentId": "9912a519-a6f6-41fe-92bf-07b99045efff",
      "name": "Student update persistence test",
      "maxClassCount": 5
    },
    "Tags": ["Student:9912a519-a6f6-41fe-92bf-07b99045efff"],
    "Timestamp": "2026-09-09T02:41:40.235475+00:00",
    "CausationId": "01a0840a-df7f-7c43-9665-0564c61c7718",
    "CorrelationId": "CreateStudent",
    "ExecutedUser": "GeneralSekibanExecutor"
  },
  {
    "ServiceId": "default",
    "Id": "01a0840a-e817-7b00-8c14-4f869aa9a78d",
    "SortableUniqueId": "063924518502423536500632865263",
    "EventType": "StudentProfileUpdated",
    "Payload": {
      "studentId": "9912a519-a6f6-41fe-92bf-07b99045efff",
      "name": "Student update persistence test updated",
      "maxClassCount": 3
    },
    "Tags": ["Student:9912a519-a6f6-41fe-92bf-07b99045efff"],
    "Timestamp": "2026-09-09T02:41:42.43232+00:00",
    "CausationId": "01a0840a-e817-7b00-8c14-4f869aa9a78d",
    "CorrelationId": "UpdateStudent",
    "ExecutedUser": "GeneralSekibanExecutor"
  }
]

For the same student ID, the name and maximum class count at the time of creation and the updated name and maximum class count remain as separate events.

When StudentProfileUpdated is applied to the state created by StudentCreated, the name becomes Student update persistence test updated, and the maximum class count becomes 3. The Projector branch and the Decider's Evolve added this time reproduce this state change.

Conclusion

By implementing the student information update step by step, I felt that I gained a deeper understanding of the event sourcing flow of "validating a change, recording it as an event, and building the state from that history," as well as the role of each process. I also thought it was very useful that persistence can be left to Sekiban, allowing us to focus on business rules and state changes.

This time, I used Codex for the implementation. Instead of asking it to implement the entire feature at once, I proceeded while checking the purpose and code of each step. Since the processing in this structure is separated by responsibility, it worked well with this kind of implementation through dialogue, and I was able to implement the feature while building up my understanding step by step.

[Event Sourcing] Trying out Sekiban DCB: Introduction

kairi — Wed, 16 Sep 2026 02:51:17 +0000

Introduction

While researching ways to ensure data consistency using NoSQL in systems with frequent reads and writes, I became interested in Event Sourcing and CQRS. During this process, I found a framework called Sekiban, which is designed for Event Sourcing/CQRS, and decided to try it out.

Sekiban - Event Sourcing / CQRS Framework

Sekiban is an open-source Event Sourcing and CQRS framework for .NET using C#. Store events in Azure Cosmos DB, PostgreSQL, or AWS DynamoDB.

sekiban.dev

What is Sekiban DCB?

According to the official website, Sekiban is defined as:

"An open-source Event Sourcing and CQRS framework for .NET. It stores not just the current state, but all changes as immutable events."

Within this framework, Sekiban DCB is an Event Sourcing framework that implements a Dynamic Consistency Boundary (DCB). It records all events in a single global stream.

Looking at their documentation, they offer three approaches: DCB Native, DCB Wasm, and Sekiban Cloud (which seems to be still in development and not yet released). For this guide, I will run it using Native C#.

Development Environment & Setup

Prerequisites:

OS: Windows 11 Pro
Environment: ASP.NET development environment ready

If your environment is set up, you can create a new project with just a few commands:

# Install the Sekiban DCB templates
dotnet new install Sekiban.Dcb.Templates

# Create project with Decider pattern
dotnet new sekiban-dcb-decider -n MyApp

# Run with Aspire
dotnet run --project MyApp.AppHost

Running the last command will start the Aspire dashboard. The official DCB documentation uses a Student and Class relationship as an example. The default project automatically includes sample code for registering students and enrolling them in classes.

Project Structure

Here is a quick overview of the created project structure:

Project	Purpose
`DCBNativeProject.AppHost`	Manages dependent services, connections, ports, and startup order.
`DCBNativeProject.ApiService`	Handles API routing and authentication.
`DCBNativeProject.EventSource`	Contains Commands, Handlers, Projectors, and data search processing.
`DCBNativeProject.ImmutableModels`	Defines Student/Class events, Tags, State, and Deciders.

To give you an idea of how it works, here is the flow for creating and getting a student record.

Creating a Student

Read the incoming JSON and convert it to a CreateStudent command.
Execute the command using ExecuteAsync.
Generate a "StudentCreated" event (in this sample, it only uses a StudentTag).
The framework saves the event to the database.
Return the result to the user.

Retrieving a Student

Receive the Student ID and find the target student using the StudentTag.
Define the expected data state using a StudentProjector.
Call GetTagStateAsync to restore the current state from the past events.
Return the result to the user.

Conclusion

As you can see, database saving operations are completely handled by the framework. I was able to save and load events without worrying about the database code at all.

Next time, I plan to add more Entities and try out some different event registrations!