Concepts

This area contains explanations and guidance on the concepts in Cratis.

Topic	Description
Event	What constitutes an event
Event Type	What is an event type
Modeling events well	How to design events that are clear today and still make sense in five years
Event Type Migrations	How event schemas evolve without breaking existing events
Event Source	What is an event source
Subject	The identity an event is about — used to key compliance concerns
Event Store	Where your events live — durably persisted in a database
Namespaces	What are namespaces within an event store
Event Sequence	What is an event sequence
Observer	What is an observer
Projections, reducers, and reactors	The three observer patterns side by side — deriving state from events vs causing side effects
Projection	How a projection declaratively maps events onto a read model instance
Designing read models	Specialize each read model for the query it serves, not for reuse
Deep dive: consistency	Immediate vs eventual consistency, and how to choose
Constraints	What are constraints
Event Metadata Tags	Metadata tags attached to events
Tagging	How to tag events for organization and filtering
Tagging Reactors	How to use tags with reactors
Geospatial Types	Built-in geospatial types for events and read models
When to use event sourcing	An honest look at where event sourcing pays off — and where it doesn’t
Glossary	One definition for each core Chronicle term

Note

Where these pages say database, you have a choice: Chronicle can persist the event store and its read models in MongoDB, PostgreSQL, Microsoft SQL Server, or SQLite.

One nuance worth carrying with you: projections and reducers are not only factories for materialized, queryable views. The state they derive from events can be stored in a database for fast queries — or computed on demand, with strong consistency, for anything that must trust the current state: validation rules, command handlers, or aggregate roots in Arc.