-
Notifications
You must be signed in to change notification settings - Fork 12
Home
AtomEventStore is a .NET library that uses the Atom Syndication Format to provide a server-less implementation of an Event Store.
It was created to solve a particular set of problems:
- It should support Test-Driven Development (particularly Outside-In TDD, or GOOS-style TDD) without adding much overhead.
- It should work well with Platform-as-a-Service solutions such as Microsoft Azure.
- It should be scalable.
- It should be lock-free.
- It should be reusable.
- It should be reasonably efficient.
As always in software development, there are trade-offs involved, so while AtomEventStore is designed mainly with the above goals in mind, it's not optimized for low latency, efficient storage, or fastest possible transmission times. It's also not designed to handle concurrent writes; the applications using AtomEventStore are expected to address this problem through applications of the Single Writer pattern.
Since AtomEventStore uses various document-oriented storage implementations, it can't provide any transaction guarantees. Some storage implementations (e.g. Azure BLOB storage) supports Optimistic Concurrency, but other storage mechanisms may not offer that.
Instead, AtomEventStore uses an ordered approach to writes. Onless you've configured the page size to be 1 or 2, most writes will only involve an update of a single document, so these write operations either succeed or fail as single units of operation.
However, when a page has been filled up, a new page is created first, after which a link is added from the old page to the new page. It's possible that the first write operation succeeds, but the next operation fails. In this case, the entire write operation fails with an exception, letting the client know that the write operation failed. While this leaves behind an orphaned page, it doesn't jeopardize the consistency of the system if the client retries the write operation.
Since Optimistic Concurrency can't be guaranteed be all storage implementations, the clients have the responsibility to prevent concurrency conflicts. The easiest way to do that is to use a single writer per event stream.
Event streams are append-only, so multiple concurrent readers can read the same event stream without concurrency conflicts.
Although AtomEventStore comes with a few usable storage implementations out of the box, it's designed around the SOLID principles in order to be reusable.
- If you need to use another storage mechanism, you can write a custom storage implementation.
- If you need to use a custom XML serializer, you can write one.
Additionally, AtomEventStore's most frequently accessed APIs are based on the already well-defined interfaces IEnumerable<T> and IObserver<T>.
Despite its priority is first and foremost to be scalable, AtomEventStore still strives towards being reasonably efficient where possible.
Since there's no server component, the client must perform all filtering and projection of an event stream. That involves reading the events from storage into memory, which, depending on the storage mechanism in use, may take some time. However, if the client knows that it isn't going to need to read the entire event stream, the choice of reading forwards or backwards through the event stream may impact performance. Therefore, AtomEventStore includes both a forward-reading Iterator and a backwards-reading Iterator.
Additionally, both Iterators utilize a read-ahead strategy where they pre-fetch the next Atom Feed page to read once enumeration starts in earnest. Still, in order to prevent too many unnecessary pre-fetch operations, pre-fetching first kicks in when the Iterator moves past the first element in a sequence. Thus, peeking at the head of the sequence doesn't trigger a pre-fetch.
The idea that an Event Store can be modelled as a Linked List was originally put to my attention by Yves Reynhout in his article Your EventStream is a linked list.