Rise Of The Robots: Event Logs vs. “traditional” Databases

This is part 1 of a three part series on event-based systems and their implications. For part 2, see “Eventsourcing: Why Are People Into That?”

You are the sum of your experiences.

So are the vast majority of software based systems. They fall into two categories:


sum(2,2) = 4




adder.Sum() = 4

The first kind of system determines its entire output from inputs at the time of interacting with the system. The second kind needs prior inputs or a combination of prior and current inputs to determine output.

Services and applications we work with as software developers tend to be of the second type:

– Making a purchase from an e-commerce site cannot be done without a catalog from which to select items to buy.

– You can’t log in without registering as a user first.

– A recommender system cannot recommend products without knowing about previous purchases by similar customers.

– Neural nets cannot be trained to recognize images without training data sets.

In order to determine what should happen next when users want to do something, this type of system needs to know its current state. We often keep state in data stores without any sense of history – our knowledge of what happened in order to arrive at the current data in (e.g.) a database is fragmented and ad-hoc at best: Timestamps on rows in tables, log files, educated guesses.

An alternative to this approach is to log the events which led to the current state instead of storing the state itself. Think of finding the current color of the traffic light with ID 1001:

Traditonal” Database (using a “TrafficLight” table):

Whenever the light changes, the CurrentColor is updated:

Traffic Light ID CurrentColor
1001 Green

Event Log

Contains a history of everything that happened to the light, from initial installation to now:

When? Traffic Light ID What?
10/23/2016 3:10pm 1001 Installed. Location: Hastings St. & Main, Vancouver, BC. Color: Red
10/23/2016 3:13pm 1001 Switched. Color: Green
10/23/2016 3:14pm 1001 Switched. Color: Amber
10/23/2016 3:16pm 1001 Switched. Color: Red
10/23/2016 3:17pm 1001 Switched. Color: Green

In both cases it’s possible to determine that the current color of the light is green.

For the “traditional” DB, one would query the TrafficLights table “CurrentColor” value.

For an event sourced system we’d have to retrieve the event log entries for Traffic Light ID 1001 in order to determine what the color of the light was at a given moment in time.

There could be many thousands of them, so in practice this could cause performance problems unless we take a snapshot of the current state and store it in a suitable location for faster access – something routinely done for real-world event sourced systems. Although there may be read models (in-memory caches, tables …) for the current state of a light, they are not the source of truth and can be deleted and re-built from the event log at any time if needed.

The important point:

Software products, services or line-of-business systems which needs to store data can be built using an event log as the source of truth instead of relying on “traditional” databases.

Why would anybody do that?

Part 2: Eventsourcing: Why Are People Into That?

Robert Reppel (@robertreppel) is Adaptech’s Director of Engineering.


  1. CQRS/ES – Or is it? – Adaptech Solutions

    […] by and for the aggregate that represent state changes in the system. This option is described in a previous blog post (by our Director of Engineering – Robert […]

  2. […] This is part 2 of “Rise Of The Robots”, a three part series on event-based systems and their implications. For part 1, see Rise Of  The Robots: Event Logs vs. “Traditional” Databases. […]