… here comes Greg Young to prove you wrong :)

We all know relational databases (RDBMSes), then we’ve learned object ones, document ones, key-value ones, etc.. Now we’re getting back to the roots to find the ***functional*** database aka database that supports event sourcing. What’s event sourcing?
Basicly, current applications (and databases) are mainly about state. Application / processing is in particular state, saves a state, transitions to state. But this is not the only way to go. Every state is achieved due to series of state changes (deltas), known as events. Events are usually simplier and easier to validate than a state that may not be easy to get fully analized. For example - instead of "Account balance is equal to 100 USD" we can enumerate the steps that caused that:
  • "Account is created"
  • "150 USD transfer IN registered"
  • "50 USD transfer OUT registered"
What’s the benefit?
  1. Audit mechanism … included
  2. We can adjust our model freely - adding a field / column? No problem, you don’t have to mess with past events.
  3. If you really need the state, you can re-generate it by running through events. If you don’t need it anymore, you can put it to garbage again.
Some basic info about event sourcing can be found:
Finally we’re on the same page, so we can proceed to the functional database!
Few days ago Greg Young has released the first version of his EventStore (http://geteventstore.com/) - functional database the supports the idea of event sourcing. It’s available at GitHub, currently in single-node version only. It runs on .NET (yay!) and has both HTTP AtomPub protocol and TCP client interfaces (the latter one is accessible via C# API). There’s a web-based Management interface with monitoring tools included. First benchmarks prove that it may work nicely in full-scale industry solutions (up to 15k writes and 50k reads on single node test rig) and it makes it an interesting option in app architectures that utilize event-sourcing approach.
Share this post