Suggest an edit

Improve this article

Refine the answer for “How to store events in an event store?”. Your changes go to moderation before they’re published.

Approval required

Content

What you’re changing

Title (EN)

Short answer (EN)

Shown above the full answer for quick recall.

Answer (EN)

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.

Markdown · drag & drop images · ⌘B / ⌘I shortcuts294 words

For the reviewer

Note to the moderator (optional)

Visible only to the moderator. Helps review go faster.