State Transition: Uncovering a New Data Model

Every database paradigm, past and present, has a data model with concepts that uniquely identifies it:

Each of these data models has its own pros and cons and is useful in their own particular use case.

EventStoreDB uses what we call the “State Transition” data model, which is useful for operational data that is shared between complex distributed systems.

What is the State Transition Data Model?

State transition is a business/domain event that represents a state change in an application. Examples include:

State transitions in the state transition data model are appended to a log, which contains all historical changes that occurred in the application.

This is similar to a credit card account where every transaction or change to your balance is stored:

Sample Credit Card Account

How State Transition is different from Traditional Data Models

Most traditional operational databases (such as relational and document databases) are focused on representing the “current state” of the application.

The state transition data model is different in two ways:

1. State Transition: Instead of updating the state of tables, it appends business/domain events to a log
2. Historical States: Instead of storing the current state of the application, it stores all state changes from past to present.

To explain this, let’s dive into a few examples.

Traditional “Current” Data Model

Imagine we developed a driver tracking system for a food delivery company

As the delivery truck moves, the system is updated

And after a series of twist and turns, it eventually reaches it’s destination

Notice how the location is always kept up-to-date with the driver’s position? This is what we call “current” data because only the current state is tracked and the past states are discarded.

Traditional “Historical Snapshot” Data Model

If we are to store the historical locations of these positions then we will have data that looks like this instead:

These individual records are what we call historical snapshots since it represents how the location or business state has changed over time.

Storing historical snapshots is great because you can perform a lot of interesting analysis. As you can see above, you can somewhat form a path from the start to the current position which helps understand the past directions and decisions taken at each turn.

However, a problem with this particular kind of snapshot is that it can be hard to understand what kind of change actually happened between each transition.

For example, how did the driver travel from point 2 to 3? We may never know.

“State Transition” Data Model

Instead of storing snapshots of locations, we can store the state change as a series of directions, which represents the action at each junction:

Immediately, you can see this forms a complete picture of the trip and it helps answer the question we had in the previous model.

It can also provide helpful analysis (e.g. estimating gas consumption for the trip) and formulate patterns for future predictions (e.g. optimal path during rush hour).

We call this the state transition data model.

One downside with this model, however, is that the current state is not immediately obvious unless you follow the transitions from the start to finish.

For example, to query for the current location of the trip, you would have to follow the directions from T1 to T7 and perform calculations to find out that J2 is the current location.

Comparing the Data Models Side by Side

There is no data model that is one-size fits all.

Intuitively, if you only need to get the current location, then the current data model is the simplest because the state transition model will require extra calculation to achieve the same thing.

However, if you want to answer deeper questions and understand “how” we got there and “why” we got there, a state transition model will provide more data and context for analytics.

And because of this and other reasons, a state transition model is much more useful within a complex and distributed system.

Characteristics of State Transition

1. State Transition is a Business Event

The key characteristic of a state transition is that it represents a business event. And a business event is arguably the most fundamental unit of change in a business application.

A business event also represents a user’s decision, action, or intention on the state of the business.

In our tracking example, a state transition would be the direction.

In an e-commerce application for example, this would a business event such as order is packed, shipped, or delivered.

2. Current State is the Sum Total of All State Transitions

Whether you’re looking at a bank statement or a patient record, the current state of a business application is made up of the accumulated effects from all the state transitions.

By following all the directions taken in the tracking example, we are able to figure out the current location of the trip:

A hotel room booking for example has a life cycle too, starting from a room being reserved, deposit paid, checked in, checked out, and balance paid. The booking’s current status is determined by the user’s actions so far.

This characteristic allows state transitions to calculate the current state. But the same can not be said the other way around.

3. State Transition is a Compact Isomorphic Model that Fits the Business Language

To represent a state transition, some APIs may return a historical snapshot with a full object graphs containing dozens or even hundreds of fields, which can be quite unwieldy and difficult to understand.

On the other hand, state transitions are typically a lot more compact (e.g. SalesDiscountApplied { rate = 0.05 }) and easier to understand because it only represents a small event or business change.

Furthermore, since events are named like user intention, it is highly isomorphic (i.e. aligned) to the business model which allows developers and business share the same language down to the database level.

4. State Transition is an Immutable Fact

State transition is inherently immutable and can not be changed because it represents an event from the past. This can help reduce uncertainty with the dataset, plus improve performance and error detection.

Summary

The state transition data model used by EventStoreDB involves appending business events to log which represents all state changes to an application. Event also represents a user intentions/decision/action.

Storing state transitions allows user to answer deeper “why” questions compared to traditional data models which can be more useful to analyze your data when it is distributed within complex systems.