Event store

An event store is a specialized database or persistence mechanism designed to store events as the primary system of record in an event-sourced architecture. Unlike conventional databases that store the current state of entities, an event store appends immutable events to a log, treating the sequence of events as the authoritative source of truth. The current state of any entity is not stored; it is derived by replaying events through a projection function.

The event store is not merely a database with a different schema. It is a different ontological commitment: the system's history is not an operational artifact to be archived and forgotten, but a first-class citizen that shapes what the system is. The event store says: what happened is more fundamental than what is. This inversion has profound implications for auditability, temporal querying, and system evolution.

Structure and Semantics

An event store organizes data as streams — sequences of events belonging to a single aggregate or entity. Each event in a stream has a unique sequence number, a timestamp, a type, and a payload. The store guarantees that events within a stream are ordered, but it makes no guarantees about ordering across streams. This is the stream-level consistency model: consistency is local to each causal lineage, not global across the system.

The append-only semantics of an event store are critical. Events are never updated or deleted; they are immutable facts about the past. If a correction is needed, a compensating event is appended. This makes the event store a monotonic data structure: information only accumulates, never decreases. The system grows in certainty, not in doubt.

Event Store as Temporal Database

Because events are timestamped and immutable, an event store is a temporal database by construction. Any state of the system at any point in time can be reconstructed by replaying events up to that point. This enables temporal querying — asking not only what is the current balance? but what was the balance on March 15? and how did it change between March 15 and April 1?

This temporal capability transforms the event store from a persistence mechanism into a narrative engine. The system's behavior over time is not reconstructed from snapshots; it is present in the event stream itself. The event store is the system's memory, and like biological memory, it is selective, sequential, and subject to reinterpretation through new projections.

Snapshotting and Performance

The cost of immutability is replay time. As event streams grow, reconstructing state by replaying from the first event becomes prohibitively slow. Snapshotting — periodically persisting a projection's state so that replay can start from a recent checkpoint — is the standard solution. But snapshotting introduces a tension: the snapshot is a cached, denormalized view of state, and like all caches, it can become stale if not managed carefully.

The deeper question is whether snapshotting is an optimization or an admission of failure. If the event store is the system of record, then any state derived from it — including snapshots — is secondary. The snapshot is a pragmatic concession to performance, not a conceptual necessity. In this sense, the event store enforces a discipline: the true state is always computable, never merely stored.

The event store is the closest software architecture has come to a phenomenological database. It does not store objects; it stores experiences. The object is the sediment of experience, and like all sediment, it conceals as much as it reveals. Any system that treats its current state as primary has already forgotten most of what it knows.