Infrastructure for Event Sourcing
Chronacta is a self-hosted event-store server. It provides versioned streams and APIs for appending, reading, subscribing, managing schemas, and working with projections. Your application retains control of the domain model.
What Chronacta provides
An event-sourced application needs more than a place to write JSON. It needs ordered streams, concurrency checks, reliable reads, and a way for consumers to track their progress.
Chronacta provides these event-store mechanisms through a network API. The application decides which events to produce; Chronacta stores them and makes them available for subsequent processing.
Streams, versions, and schemas
Each stream has an ordered sequence of events and a version. An expected-version check rejects an append based on an outdated stream version. An idempotency key allows the same append request to be retried without adding a duplicate under the API's idempotency contract.
Global positions support reads across streams. Subscriptions deliver events to consumers, and projections derive read models. The schema registry validates event payloads against registered JSON Schema definitions.
In a DDD application using Event Sourcing, a stream commonly stores the events of one aggregate instance. The aggregate enforces invariants; the stream version helps prevent concurrent decisions from being committed against stale state.
Command handling and queries
A command handler loads an aggregate through a repository, invokes domain behavior, and persists the resulting events. The repository can reconstruct the aggregate from its stream and append new events with the version that was read.
In a CQRS design, query handlers read models prepared for their queries. Projections populate those models by processing events. Read models can reside in application memory, a relational database, or another appropriate store.
A projection is the transformation; a read model is its result. Changing projection logic may require rebuilding the read model. It does not change previously recorded events or automatically correct mistakes in command handling.
Product boundaries
Chronacta is not a relational query engine. Use an appropriate database for joins, search, and analytical queries over derived data.
Chronacta is not a drop-in replacement for Kafka or NATS. An event store and a message broker can serve complementary roles in the same architecture.
Chronacta does not implement your aggregates, command handlers, or domain invariants. It is infrastructure, not an application framework.
You deploy and operate the server. Chronacta provides a single-node edition; Enterprise adds capabilities for high availability and broader operational requirements.
Integration across boundaries
Keep ownership of streams and event contracts explicit. A bounded context owns its domain model; other contexts should not depend on every internal event representation.
A subscriber can translate domain events into integration events for another bounded context. Postgres may store read models, while NATS or Kafka may distribute integration events where external transport is required.
Coordinate long-running processes in application components such as process managers. Chronacta stores and delivers events; it does not determine the business process.
From development to operation
Start with one aggregate, one command handler, and one projection. Test successful writes, version conflicts, retries, and read-model rebuilds.
Before production, define backup and restore procedures, consumer recovery, data access, monitoring, and event-schema evolution.
Choose Chronacta or Enterprise according to measured capacity and requirements for availability, identity integration, recovery, and administration.