NOTE: major refactoring underway. Event Horizon started as a promising R&D project that wasn't production-ready due to its persistence layer not being a highly available datastore.
The v1 was solid as far as the (code-side) UX in the using application was concerned, so I took what was good in v1 and started building v2 with a better, easier persistence layer (AWS DynamoDB).
This document is work-in-progress and describes the progress of the EventHorizon v2.
If you want, you can browse the repository at the old version.
Contents:
Steps:
These apps use EventHorizon:
- CertBus
- Edgerouter
- Lambda-alertmanager
- Deployer
- Varasto (soon)
- Passitron (soon)
On use cases that require consistency, it is provided via optimistic locking. Optimistic locking means that if you don't want to sometimes show error message for user to try again (this would be bad UX), your application has to re-try the write:
- refresh its read model so you have the data that caused the conflict
- run the validations again
- append the event again
There's a helper for this: Reader.TransactWrite and here's how using it looks in a real-world application.
There's even a test that tests for conflicts on concurrent writes.
See pkg/ehreader/reader_test.go for example test case that demoes how to use the reader to read data from EventHorizon.
I hope you can see from the test code that we also great testability support for
implementors of EventsProcessor interface where you don't have to do anything special for
your production code to be testable.
For receiving realtime data you would call Reader.Synchronizer.
Our events table and snapshots table mostly follow the design from page 41 onwards in CQRS Documents by Greg Young.