Subscriptions $et- vs $ce- and out of order events

EventStoreDB
1

Hello,

i’ve implemented my event dispatcher like described in this post [1].

It iterate over all event types in my application and is using

SubscribeToStreamFrom(string.Concat("$et-", eventType.Name), …);

It also stores the last successful processed event id and subscribes on the next startup again from this position.

This implementation has the advantage to receive only “my” events from the GetEventStore and the flexibility to replay only all events from a specific type.

But if’ve one subscription for each event type in my application. Is it bad to have “so many” subscriptions with the C# client?

I also have to deal with out of order events, e.g. CustomerRelocated arrived before CustomerCreated. The easiest way was to fail with an exception in the EventAppeared handler and then to restart the subscription from the last working position (in hope the CustomerCreated event arrived in the meantime). What do you recommend to handle this?

Another idea was to use the $ce- projection and subscribe to each aggregate type of my application, where i get all events from this aggregate in order. But its less flexible then the $et- approach and i could still have out of order events in my read model.

Or using the $all stream … but then i receive tons of events that i’m not interested in, e.g. stats or stuff like $$$et-$statsCollected, $$$et-$metadata, …

What is a recommend way to go?

Thanks.

[1] https://groups.google.com/d/msg/event-store/fC9O1d0GnEc/9e5DbaHtL3cJ

2

Using the $all and dropping would be the simplest. Are you worried about the network traffic or?

Alternatively you could easily build a $all equivalent with a projection that had no system events in it. Eg

FromAll().when({

$any : function(s,e) { if(!e.type.startsWith("$") linkTo(“myall”, e)}
})

3

+1 for almost-all stream. Using $all can get a bit pricey if your
eventstore is in the clouds and you are rebuilding your readmodels a
lot.

4

My initial idea was to have an projection for each readmodel(group), with just the events it required, but it made updating and restarting them complicated. I guess I could version them, and delete the old ones when there are changes.

What would be ideal is if I could subscribe to multiple streams from the client, and have them merged and ordered with global eventposition.

i.e:

SubscribeFrom($et-EventA, $et,EventB, $et-EventC) etc…

/Peter