# 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](/docs/eventsourcingdb/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](/docs/eventsourcingdb/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](/docs/eventsourcingdb/installing-eventsourcingdb)** and **[Running EventSourcingDB](/docs/eventsourcingdb/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](/concepts/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](/docs/eventsourcingdb/verifying-store-integrity)**, **[Security and Access Control](/docs/eventsourcingdb/security-and-access-control)**, and **[GDPR Compliance](/docs/eventsourcingdb/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**.

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](/concepts/versioning-events)**.