What I expect from some system managing storage of streams of events, intended to be used in an event-sourced system.
- ability to create streams
- ability to delete streams
- ability to use optimistic locking on stream level
- ability to write a batch of events in one stream atomically and durably
- ability to read events from one stream
- ability to read all events in the store ( the so called "$all" stream)
- ability to read forward and backward
- ability to read from some position in a stream or from the "$all" stream
- ability to remove events before some position in a stream
- ability to remove events before some time
- ability to have subscription (though I might consider it a bonus)
- ability to read events from a stream in commit order
- ability to read events from "$all" stream in commit order
- ability to have metadata on stream level
- ability to have metadata on stream level even if the stream does not exists yet
- ability to have metadata on events
- idempotent writes (more on that later)
other functionalities are bonuses, some bonuses are evil
Examples of bonuses
- ACL on streams
- server side managed subscriptions
- system streams
- deleted streams
Examples of evil bonuses
-
Transactional write on multiple streams:
- you can avoid it by carefully designing your streams
-
allowing to participate in Distributed Transactions
- e.g. writing to a stream and updating a read model in another storage atomically