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
eventstable, whereaggregate_id + versionis the unique key. - NoSQL: MongoDB or DynamoDB work well for streaming scenarios.
3. Storage principles
- Append-only: no updating or deleting events.
- Immutability: every event is a fact, it cannot be corrected.
- Versioning: events must be replayed in the order they happened.
- 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_idare 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 readyPremium
A concise answer to help you respond confidently on this topic during an interview.