Thread by @daveremy

A tweet stream on Event Stores as a new class of Database EventStoreDB eventstore.com is an example of an Event Store type DB.
1/

Event Stores could equally be called log, ledger, or stream databases but they came out of the Event Sourcing space which named them Event Stores. DB Engines link to Event Stores: (db-engines.com/en/ranking/eve…)
2/

The idea of an Event Store is straightforward but has profound implications.
3/

Traditional databases are optimized for storing and querying current state. A simple way to say this, if there is an UPDATE or DELETE the data is thrown away (admittedly oversimplified)
4/

There are two major differentiations for Event Store databases, they are 1) non lossy and 2) built for “real time” streaming access
5/

Event Stores are non lossy in two ways.
6/

One, rather than throwing away updates and deletes the state changes are kept in the form of Events.
7/

Two, these Events have meaningful names which help preserve the business context at the
database level. Events modeled at the business level can be persisted all the way into the db
8/

The other key feature of Event Stores is that “real time” streaming is first class. It is the fundamental access pattern
9/

Traditional database technology optimizes putting data into pools (versus streams) meant to be queried. Streaming is at best low level and second class
10/

One way to think of Event Stores is an an unbundling of the write ahead log of traditional databases (or distributed consensus implementations)
11/

Event Stores essentially become the transaction log for the enterprise with the prime purpose of transacting “source of truth” data that is then can be radiated out in “real” time to the enterprise
12/

Event Stores keep the underlying state changes in an ordered sequence, a log, with a monotonically increasing number associated with each state change
13/

This monotonically increasing number enables cache synchronization across the enterprise
14/

Caches in this context are an abstraction of a large set of use cases that are particularly relevant in modern distributed systems. Martin Klepmann describes this well in his talk Turning the Database Inside Out (confluent.io/blog/turning-t…)
15/

Materialized views, in memory read models, dependent autonomous services, occasionally connected systems are some of the many examples of “caches” with requirements for cache synchronization
16

With an Event Store as the underlying source data, a cache can keep the sequence number associated with the latest change it knows about (in ESDB this is called the checkpoint)
17/

If either the cache or the Event Store becomes unavailable for some period of time, at the point they are reconnected, the cache can “catch up” from its last known synchronization point
18/

In EventStoreDB this is called a “catchup subscription” and it is a fundamental feature of the Event API
19/

This non lossy and real time nature of Event Stores is especially relevant related to two major trends in the software industry 1) autonomous (micro)services and 2) the explosion of integration and analytics innovation
20/

One of the requirements of most (micro)services is autonomy. To accomplish this, rather than calling out for data, the data is cached. If the source service goes down the autonomous service can continue. When the source service comes back up it can resynchronize
21/

This requirement for autonomous (micro)services has become one of the strongest drivers for ESDB adoption growth
22/

The non lossy and real time characteristics of Event Stores position them well for helping enterprises leverage the explosion of innovation in integration and analytics technologies
23/

Obviously if the data was thrown away it cannot be leveraged for analytics. A key aspect of the value of the ledger like nature of Event Stores
24/

Event Stores are designed to “connect” and “project” to data technologies optimized for their own integration or query use case. This could be Kafka for integration, Snowflake for your data warehouse, a public blockchain, etc
25/

Not only can Event Stores be connected in real time but, since the Events are persisted in stream format, they can be replayed from the beginning
26/

When requirements change or new requirements emerge the history of events can be replayed and reshaped. New reports can be created, as if they were always there
27/

There are many other potential benefits for Event Store databases such as improved audit, time travel (for debugging and what if), improved failover and recovery, private ledger and more (more posts/blogs on these to come)
28/

Of course Event Stores do not come without tradeoffs. Mainstream developers are less familiar with Event Stores and building systems with Event Sourcing patterns. There are more moving parts
29/

The Event Sourcing development pattern, the body of knowledge and community that has built around that over the last decade is critical to building successful systems that result in the Event data model used by Event Stores
30/

For me at least, a reason I have become so committed to Event Store, and the importance of Event Stores as a new class of database technology, is the potential for Event Stores to become a leading operational database option for modern systems
31/

The non lossy and real time characteristics of Event Stores and the idea of unbundling transaction logs making them first class is game changing and is super relevant to modern systems development requirements
32/

Whether you are a CTO, Architect, or Developer it is important to be aware of this alternative and assess whether it is a fit for your project and/or enterprise
33/