Design Principles

This guide explains the core principles behind the design of EventSourcingDB. These principles shape not only how the system works, but also what it deliberately leaves out. They reflect our commitment to clarity, correctness, and simplicity – and they define how EventSourcingDB differs from general-purpose databases or message-driven systems.

Understanding these principles will help you assess whether EventSourcingDB fits your architecture, your workflow, and your expectations of long-term system evolution.

Purpose-Built for Event Sourcing

EventSourcingDB is not a general-purpose database that happens to support events. It is a dedicated event store, designed from the ground up to meet the demands of event-sourced systems. The data model, APIs, and guarantees are all shaped by the realities of dealing with immutable, ordered, and meaningful domain events.

Rather than extending existing storage systems to approximate event behavior, EventSourcingDB embraces the event sourcing model fully – making it simpler, more robust, and easier to reason about.

Immutable, Ordered, and Safe by Design

Event-sourced systems rely on a consistent, tamper-proof history of everything that has happened. To support this, EventSourcingDB enforces strict immutability, guarantees the ordering of events within a stream, and ensures atomic write operations. No partial writes, no corruption, no guesswork.

All events are written to an append-only log. Every write is deterministic. Even under failure conditions or concurrent access, the event log remains correct, consistent, and verifiable. These are not implementation details – they are core assumptions, enforced by design.

For additional details, refer to Preconditions.

Optimized for Real-World Use

EventSourcingDB includes built-in support for snapshotting, optimistic concurrency, and replay – not as optional extras, but as first-class capabilities. These features are essential for working with long-lived aggregates, evolving domain models, and high-throughput systems.

Instead of forcing teams to build their own replay strategies, conflict resolution mechanisms, or caching layers, EventSourcingDB provides these building blocks out of the box – tested, documented, and predictable.

For more information, see Snapshots.

Simple to Run and Easy to Integrate

EventSourcingDB was designed to be operable by real teams, under real constraints. It requires no external brokers, no container orchestration, and no specialized runtime. You can run it locally, deploy it to the cloud, or integrate it into your infrastructure with minimal configuration effort. EventSourcingDB is designed to play well with other components, such as read stores, message queues, or analytics pipelines – without locking you into a specific stack.

The system communicates over plain HTTP and is compatible with any platform, language, or toolchain. You don't need adapters, SDKs, or plugins to get started – though you're free to use them if you like. Integration should be seamless, not invasive.

Further information can be found in Installing EventSourcingDB and Running EventSourcingDB.

Transparent and Test-Friendly

There are no background processes, hidden retries, or implicit assumptions. What you write is what gets stored, and what you query is what gets returned. Every part of EventSourcingDB is designed to behave predictably and be observable in production, in development, and in automated testing.

We believe systems should be understandable – even under load, even in failure. EventSourcingDB provides clear error messages, consistent semantics, and transparent APIs to support fast feedback and reliable debugging.

See Testing Event-Sourced Systems for more details.

Secure by Default, Ready for Compliance

Correctness is a prerequisite for trust. EventSourcingDB enforces atomicity and consistency in every write. Event streams can be verified using content hashes, enabling audit-style verification similar to blockchain-like ledgers.

Security is not an afterthought. While advanced features like encryption and fine-grained access control are on the roadmap, the current system already provides strong isolation between streams, deterministic write behavior, and a simple but effective API token model to protect against unauthorized access.

See Verifying Store Integrity, Security and Access Control, and GDPR Compliance for additional information.

Designed for Evolution, Not Complexity

Event-sourced systems are not static. Business rules change, domain models grow, and new projections or interpretations are introduced over time. EventSourcingDB embraces this reality.

The system supports replay, filtering, pagination, versioned events, and snapshots – all intended to help teams adapt without rewriting or migrating core data. At the same time, we avoid adding features that introduce hidden coupling, increase operational fragility, or obscure the mental model.

Our aim is to offer a durable foundation, not an all-in-one solution. EventSourcingDB supports replay, filtering, pagination, versioned events, and snapshots – all designed to help teams evolve their systems without migrating or rewriting core data. At the same time, we avoid features that introduce hidden coupling, operational fragility, or unnecessary abstraction.

Instead of chasing completeness, we prioritize clarity and long-term maintainability. EventSourcingDB will continue to grow carefully, guided by practical needs – with simplicity as a constant principle.

For additional details, refer to Versioning Events.