A Beginner’s Guide to
Event Stores

This guide is for developers and software architects who have built event sourced applications and are wanting to learn about event stores and how they compare to traditional databases.

Introduction

If you’ve built an event-native application you may be considering if your current database set up is suitable for the storing of events. 

You may be using Kafka, MongoDB or Postgres or considering building your own, but there are drawbacks to not having a database built specifically for Event Sourcing or event-driven architecture.

In this guide we explore the main reasons why you need an event store dedicated to Event Sourcing.

What Is An Event Store?

To put it simply an event store is an event-native database focused on storing events in an append-only log. Each change that takes place in the domain is recorded in the database.

An event store is designed to store the history of changes and the state is represented by the append-only log of events. The events are stored in chronological order, and new events are appended to the previous event.

This means that in an event store, events are immutable, they cannot be changed but their effects can be altered by later events. 

An Event Store vs A Relational Database

What's the difference between an event store and a traditional relational database? Let's take a look.

Relational databases lose data

In today’s data driven world, one of the biggest challenges with relational databases is around intentional data loss. Relational databases store current state; when a row is updated or deleted, that data is thrown away, taking with it your data integrity and insight around what exactly happened. 

Relational databases aren't highly optimized for read or write tasks

While relational databases provide a general technology for both reading and writing, they aren't highly optimized for either task. As data gets normalized and split into multiple tables, write transactions can span many tables and queries will often require a large number of joins to read the data. This has led to the development of more query-oriented analytics databases to compensate for these limitations.

Diagram of a traditional database vs eventstoredb

Event stores are natively focused on storing events

Unlike relational databases, an event store is natively focused on storing events as an immutable sequence. Event store databases, like EventStoreDB, keep the order and business context of any state changes. Whilst events in the log cannot be changed, their impacts can be altered by later events. 

The key features of an event store include streaming, transformation (projections), subscriptions, and replay.

In addition, event stores take advantage of the economic trends in modern storage costs to make it feasible to store every state change along with its business context. The state change is the most fundamental approach to data storage, which can subsequently be “projected” into other existing data models such as relational, graph, or document.

Event stores keep the context of your data

An event store database concentrates on capturing data at its most elemental level and projecting (transforming and streaming) it into the shape required by downstream systems or technologies. 

Event stores have the capability to replay & project events

The capability to replay events and project them into new forms as requirements evolve and novel data technologies surface is a standout feature of an event store database.

To illustrate how this works in practice, imagine an “InvoiceIssued” event is appended to the log one day, only the address the invoice was issued to was incorrect. In traditional databases, the old address would likely be overwritten. But in your event store database an “InvoiceVoided” event will be added to show the original invoice was incorrect;  then a new “InvoiceIssued” event will occur with the correct address. 

For each event, the dates and times will also be stored. You can even store who made the changes to your data, allowing you to go back in time to understand what occurred. You’ll therefore retain the business context -  a wealth of information that's often lost in traditional databases.

Further reading:

Top 5 Reasons You Need An Event Store

1. Ability to time-travel

A big part of an event store’s power comes from its ability to replay events over time. Not only allowing you to go back in time but giving you richer data to help with analysis and forecasting.

2. Infuse meaning into your data

Switching from a traditional database to an event store can help bring new meaning to your data due to the fact that events are immutable stored and contain the context of the event.

For example, it’s like the difference between being given a hiking map that just shows you the end point vs a detailed set of directions.

3. Decouple external systems from your core logic

The problem with a lot of state based models is that they are tightly coupled with the core logic of your application. And because of this consumers of the state based models become dependent, not just on the data but also on the code base as well. One of the superpowers of EventStoreDB used with event sourcing is the ability to decouple complex systems.

4. Root cause analysis

Connecting business events to their originating events allows for thorough root cause analysis. This traceability ensures visibility into entire workflows, enabling you to pinpoint the exact source of issues and streamline the troubleshooting process. Traditional databases require you to refer back to changelogs, check external data sources and then piece together that information.

5. Enables you yo integrate with other technologies

An event store can act as the ‘brain’ of your business storing all business critical information.  For example, EventStoreDB can integrate with other technologies like Kafka, MongoDB and PostgreSQL which can distribute the data to other systems and analytics technologies.

Find out more by watching our webinar about the benefits of EventStoreDB for event sourcing.

Why EventStoreDB?

EventStoreDB is an operational database that stores your critical data in streams of immutable events. It was built from the ground up for Event Sourcing and offers an unrivalled solution for building event-sourced systems.

  • Immutable Data Store EventStoreDB stores your data as a series of immutable events over time, providing one of the strongest audit log options available.
  • Guaranteed Writes Writes are committed to disk which makes it ideal for a “source of record” database.
  • Projections Projections allow you to react to events as they are written, and to create new read models when interesting combinations occur.
  • High Availability EventStoreDB can run as a cluster of nodes containing the same data which remains available for writes provided at least half the nodes are alive and connected.
  • Optimistic Concurrency Checks Writes supports an optimistic concurrency check on the version of the stream to which events are written. If the check fails during writing, the server returns an exception to let you know.
  • Multiple Hosting Options EventStoreDB can run as a server on most platforms from desktop operating systems like Windows, Linux and macOS, to Windows and Linux servers, Docker containers, and orchestration tools such as Kubernetes.
  • Client Interfaces There are client SDKs based on the gRPC framework for all major languages and platforms including .NET, Java, Go, Node, Rust and Python.

Summary

An event store, designed specifically for event-native applications, gives you a wealth of benefits compared to traditional databases or messaging tools:

  • Prevents the loss of data & keeps business context
  • Allows you to stream your data
  • Gives you real-time data processing
  • Improves business agility and flexibility
  • Enables you to integrate with other technologies

When looking for an event store database check for these key components:

  • It’s an operational database as opposed to a messaging tool
  • It immutably stores data
  • It provides guaranteed writes
  • It can handle Projections
  • It’s set up for optimistic concurrency
  • It provides high availability and scalability