Event Store - my learnings

I have been evaluating Event Store and thought I'd write my learnings. The context is based upon an Order Processing system, which receives Orders (OrderCreated) and processes them through their lifecycle.

 1. Hard deletes are really hard! If you are testing and creating streams and deleting them, if you do a hard delete you really CANNOT recreate a stream. Of course, this is not a natural thing to do in a real world environment, but beware if playing around. The only way to get around it is to use a new DB. 

2. The browser window does a lot of caching. I (soft) deleted a stream and then went back to the Stream Browser window. It still displayed the stream I deleted and when I clicked through it displayed the events within the stream. This led me to hard delete it which caused other problems. In reality, the browser is caching all the information. Either use Developer Tools to clear the cache or use the API: the stream HAS been deleted.

3. When modifying a projection, reset it. I had errors when I modified a projection and didn't reset it. 

4. Consistency is guaranteed within a stream, not across them. If in pseudocode you write:

for (var i=1; i<6; i++)
{
    CreateStream(i);
}

you will not necessarily see 5,4,3,2,1 in the Most Recently Created Streams and projections upon the Streams will be sequenced accordingly.
This is because the parallelism of the writes means that any that were initiated at almost identical times will be written to the log as each task completes. If you were to add a small sleep in the for loop you would see them being sequenced in the same order as the API calls.

Remember, consistency is guaranteed WITHIN a stream, not ACROSS a stream. Events within a stream will be written in the sequence that they are received.

This consistency guarantee may help you decide how to arrange your streams. If my stream was AllOrderEvents, and it contained all of the events for all of the orders, then this may incur a performance hit as concurrent writers will all be trying to write into one log for all orders and they may get version conflicts. We don't care about the exact sequencing of one order to another, but we do care about the sequencing of events within an order.

Furthermore, remember that in a distributed event-driven system, we should not rely upon Message Ordering. Some message buses may provide ordered messaging, but they will do this at a cost to performance and storage.