Skip to main content

How to store events in an event store?

In event sourcing, all state changes are stored in a special store, the event store, where each object is represented as a sequence of events. The main idea: nothing is overwritten, everything is added as new events.

1. Storage structure

Each event is a separate record with the following fields:

javascript
{ event_id: UUID, // unique identifier aggregate_id: UUID, // which object (for example, an order) it belongs to event_type: "OrderCreated", payload: {...}, // event data timestamp: "2025-11-12T16:00:00Z", version: 3 // sequence number for replay }

Events are sorted by aggregate_id and version: this is the history of a specific object.

2. Where to store events

  • Specialized event store systems: EventStoreDB, Axon Server, Kafka (log-based), Cassandra.
  • Relational databases: events can be stored in an events table, where aggregate_id + version is the unique key.
  • NoSQL: MongoDB or DynamoDB work well for streaming scenarios.

3. Storage principles

  1. Append-only: no updating or deleting events.
  2. Immutability: every event is a fact, it cannot be corrected.
  3. Versioning: events must be replayed in the order they happened.
  4. Projections: separate tables with aggregated data ("read models") are built for fast queries.

4. Reading and rebuilding state

To get the current state:

  • all events for an aggregate_id are selected,
  • they are replayed in memory in chronological order,
  • "replay" logic is applied, forming the final state.

5. Storage in production

  • Events can be archived and split by type or time range.
  • Checksums are added for safety (to verify integrity).

Summary:

In an event store, data is not updated but appended as a stream of immutable events. This creates a reliable history log from which any state of the system can be restored.

Short Answer

Interview ready
Premium

A concise answer to help you respond confidently on this topic during an interview.