Event sourcing and CQRS

Celeriant assumes one model: the source of truth is an append-only log of events, and every queryable view of your data is a projection built from that log. State is derived, not stored. This page is the worldview the rest of the docs lean on, not an event-sourcing tutorial.

Celeriant is the write side

CQRS splits the write side from the read side. Celeriant is the write side: it stores events and enforces the invariants that govern them. It does not answer queries about state. You project the log into a read store (Postgres, a search index, a cache) and query that. See Building a read model.

This is where Celeriant stops being a drop-in for your SQL database. If your system does not already separate reads from writes, that separation is the real cost of adopting it, not the API. See when not to use it.

Why a store built for this

Event sourcing leans on one operation: the conditional append. Commit this event only if the aggregate has not moved since I read it. Postgres can do it with a version check inside a transaction, at relational-database cost per write. Kafka cannot do it at all; a producer cannot say "append only if nothing else was written for this key since I looked". In Celeriant it is the ordinary write path. See Optimistic concurrency.

That one operation lets you enforce a business invariant at write time instead of reconstructing it later with sagas, outboxes and reconciliation jobs.

The shift from state-first

Coming from a CRUD system that publishes events as a side effect of state changes? Flip it. The event is the write; state is a view you rebuild. That is a real change in how you model, so do it deliberately. See Coming from Kafka.

New to event sourcing? Martin Fowler's notes on event sourcing and CQRS are the standard primer.