Lock free

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. Unless 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 by 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.