Dave Remy Profile picture
6 Apr, 19 tweets, 3 min read
Most people who learn about Event Sourcing learn it as an application design pattern, which of course it is. However, IMO, the big WHY for Event Sourcing is the Event data model that this pattern enables
To date myself I was fairly early in the relational database space working for IBM in the mid 80s when relational started to take off. A big driver of relational db adoption was that Relational (vs Hierarchical) did not you require you to lock in your query access pattern
When (not if) business requirements change Relational offered assurance you could query data in ways not anticipated in the original design. CTOs, Architects, Devs, even CEOs got the message, most knew that businesses live or die based on their ability to cope with change
The Event data model, underlying Event Stores and Event Sourcing, reminds me of the same type of change in thinking that relational engendered. The Event data model goes one step further, to a more fundamental core data model component, an Event
The Event data model keeps state changes as the fundamental data model and allows you to then “project” into whatever other data model you need to leverage that data on the query side.
This could be relational, document, graph, you name it - when business requirements change you change or regenerate your query model to fit your needs
The Relational data model, with all its power is lossy. The data that it captured was provably queryable however it’s focus is on keeping current state of the data. Deletes (obviously) and Updates (less obviously) are lost .. it is not possible to query data once it is gone
The Relational data model “collapses” the underlying state changes into a specific current state data model that is flexible but not particularly optimized for either querying or writing
A Relational “normalized” data model will break logical business entities into multiple tables which must both be written too and read from to get the data … as so many of us know when needing to do 10 table joins for common queries
Event Stores and the event data model represent a separation of concerns with Event Store focused on optimizing append only streams of events and feeding those events in “real time”, to whatever query engine most appropriate for your use case
Event Store databases and the Event data model may seem new and revolutionaryish, in some ways they are, however they are also evolutionary. Most db technologies as well as distributed consensus algorithms have a “log” as their fundamental underlying data structure
Event Stores are unbundling this log and proposing it as the database itself
A sign of the growing maturity of the Event data model is the Event data design methodologies that have emerged from analysis down to implementation (event storming, event modeling, etc.)
One aspect of the Event data model is that underlying events implemented at the db level tend to be isomorphic with the design artifacts. In other words the events in the db tend to represent business understandable events and language
This can have profound implications, your systems monitoring will also be business monitoring for one …
Event Store’s have the potential to be the next generation of operational, “source of truth”, transactional database technology
Their nature of being non-lossy with a first class streaming API put them at the confluence of multiple macro trends such as (micro)services, the explosion of powerful analytics and integration technologies, blockchain, and AI
Event Sourcing as an application development pattern is a powerful tool for building modern systems, especially distributed asynchronous ones. This is an important consideration and may be enough for you to decide to choose the Event Sourcing pattern ...
However there is another powerful consideration, arguably the most important, which is the value of underlying data and the Event data model itself ...

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with Dave Remy

Dave Remy Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @daveremy

30 Mar
A tweet stream on Event Stores as a new class of Database EventStoreDB eventstore.com is an example of an Event Store type DB.
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…)
The idea of an Event Store is straightforward but has profound implications.
Read 33 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!