Multi-user Event Store
• Mark Eschbach
For a while I have been toiling with the ideas around event stores. Although I definitely have my own path towards event stores, I am definitely not the first to walk down that path. Talks like Design Patterns: Why Event Sourcing? tell some interesting stories. Their stories have made me curious what a multi-user event store backing a system would look like.
I suppose the best place to start is storage. At the core I am starting with just memory storage which will hold a record. Should be pretty simple.
Fairly straight forward as I had suspected. The first implementation will just use an in memory store with a simple
array. Later this will run into an issue with latency however I am hoping marking these as async
will provide the
flexibility needed for on-disk or remote storage possible. We will see.
Thinking through future designs I am a little bit afraid I am building something like Kafka, which is always be leagues ahead of anything I can created. Ideally this would be an API to process events from something like Kafka or ZeroMQ, replacing the in-memory store. This means the API should deliver easy methods for interpreting events, including filtering events to be interpreted.
From my experience you might get luck with systems and be able to write a query native to the target data store and not have to perform any additional post processing on the results. This is often the case with highly structured systems allowing ad-hoc queries like relational data stores. Given the current interface does not allow native queries of the storage type I do not think I can get away with this. For now I will have an application side event filter and just hand all of the events to it. Definitely not ideal when scaling up but I will wait until I have a reason to tackle that complexity along with eventing from the data store.
So effectively I have the method async EventStore#materialized( filter, view ).
This will pass each event to the filter
and when it returns true
will pass the event to the view
. If I add more
structure to the events I would be able to provide more effective filtering. Something to explore later on. Attaching
this to the EventStore
itself was probably not the best idea, as there are probably more use cases than can be
covered than this simple interface. Creating view check points is probably a great example, or event reducing the
burden of view
to really be a reducer similar to those in Redux.