I’ve been using NEventStore to do a prototype and I’m moving now to GES to compare them. One difference that I noticed is that NEventStore stores everything in the same collection (I’m using MongoDb), with a StreamId. In GES, we are creating a new stream for each Aggregate saved, even if it’s the same type, is that correct?
Now, I’m trying to dispatch all the events and I noticed that with this approach, I have to subscribe to all the events in the eventstore… will it affect performance?
Another difference is that NEventStore keeps track of all the events already dispatched, I think I can reproduce the same behavior using metadata. Is there any other way? I can also keep the record of the latest position in the database in case the application restarts…
NEventStore’s ‘dispatch’ puts the solution in the wrong place - these subscriptions should be subscriber driven (store the position with your view model) rather than publisher driven as otherwise you can’t rebuild a single projection (for example).
Ok, it eliminates the need of Masstransit between the read model and the write model, which is valuable, but I will still need to publish it to other services.
With this approach,
I would have a system with multiple services using the same eventstore, each service has its own domain and saves the aggregate to the eventstore.
I would have multiple services for the read model or one service, not sure yet. I can have one service using MSSQL and I need at least one with ElasticSearch for the search.
I must have only one readmodel-backend to synchronize with all the read models, or else I would need some logic to prevent publishing the same event multiple times.
How do I scale this syncronizer?
I’m not feeling very confident about this approach, because then I need some logic to prevent publishing the same event multiple times from different streams subscribers or have a system hard to scale. I bet I’m missing something here, and you guys can help me.
segunda-feira, 29 de Junho de 2015 às 18:01:12 UTC+1, Bruno Costa escreveu:
For projections you rarely want competing consumers you instead want a
client driven subscription (catch up subscription) each read model
would have its own catch up subscription. For more on this see https://www.youtube.com/watch?v=GbM1ghLeweU
@Greg, I’m not authorized to use competing consumers at the moment, so I will have to live with it and need Masstransit (or anything similar) to send the events to other services.
But with this mechanism, I need a unique component which will be responsible to read the stream and send the events to Masstransit, right?
My question is: how do I scale out this easily?
terça-feira, 30 de Junho de 2015 às 22:20:56 UTC+1, Greg Young escreveu:
I’m trying to keep all the services that will be running projections with GES, but in the end, we might have some services creating they own projections (read models) based on the events we send. It’s a big company and we cannot ensure how will they use/react to those events.
quarta-feira, 1 de Julho de 2015 às 15:50:30 UTC+1, Greg Young escreveu: