Chronicle
Chronicle
Event sourcing, the productive way
For information systems, this is the default architecture we recommend: store every meaningful change as an immutable event — the complete history of what happened — and turn those events into exactly the read models, reactions, and projections your application needs. Chronicle gives that event log a gRPC boundary, storage choice, and tools you can actually operate. Get started → · Architecture →
Start here
Section titled “Start here”Why we see full history as the default for information systems — audit, time-travel, many read models from one source of truth — and where the exceptions are.
Get startedScaffold a project from a template and watch one event flow through a projection and a reactor — in minutes.
Choose an application host modelCompare console, worker, and ASP.NET Core hosts — with Arc as a layer on top — and run the kernel locally or under Aspire.
Build the library tutorialLearn the model by building a small event-sourced system one concept at a time.
Architecture wins
Section titled “Architecture wins”Chronicle is a client-server kernel with gRPC/protobuf contracts. The .NET client is first-class and most mature; TypeScript and Elixir clients/contracts and a gRPC-level Kotlin client are generated from the same protocol.
Storage agnosticRun the event store over MongoDB, PostgreSQL, Microsoft SQL Server, or SQLite, with the same event model above it.
Processing lives in the kernelDistributed, stateful processing is the kernel’s job: event sequences, observers, jobs, and recovery run inside the runtime, not in your application code.
Observable and operableWorkbench, CLI, OpenTelemetry, recommendations, read-model inspection, failed partitions, jobs, and replay make the running store visible.
Understand the model
Section titled “Understand the model”How the kernel, client, storage, and read models fit together.
Concepts & glossaryEvents, event sources, projections, and the rest of the vocabulary — defined once.
CRUD, EF Core, and ChronicleMaps tables, rows, and SaveChanges onto events so the shift makes sense.
Build with the core pieces
Section titled “Build with the core pieces”The immutable facts at the heart of everything — how to model and append them.
ProjectionsDeclare read models that stay in sync as events arrive — no update code.
Choose a read-model styleSee model-bound projections, declarative projections, and reducers build the same read model.
ReactorsDo something when an event happens — notify, integrate, or trigger a command.
Read modelsThe queryable state your application reads, derived from the event log.
ReducersFold events into state imperatively when a projection isn’t enough.
Data integrityEnforce uniqueness with kernel-side constraints and guard racing appends with concurrency scopes — both checked before commit.
ScenariosTask-oriented recipes — rebuild a read model, enforce uniqueness, react to an event.
Chronicle stands on its own — run it from any .NET host, with no other Cratis product required. When you want a typed full-stack app on top, Arc adds the CQRS boundary and Components renders it. CQRS and event sourcing fit naturally together, but neither depends on the other. See Why developers choose Cratis for how the pieces fit.