Using Event Store as a messaging mechanism

EventStoreDB
#1

Hello,

We are using SOA without any messaging mechanism and we are starting to have some problems with services dependencies and I’m doing some prototypes to prove that Event driven architecture is the way to go.

I’ve looked at NServiceBus and Masstransit (using RabbitMQ) and now, I’m starting to look at Event Store. With persistent subscriptions in the next release, I’m starting to wonder if I still need RabbitMQ/NServiceBus/Masstransit at all.

Using Event Store as a messaging mechanism I think I will have all the features I need from messaging, plus, the possibility to do catch-up (replay) subscriptions. This last one seems very useful, I can throw away any service of my system, create a new one and just do a catch-up subscription to load data into my new service. It’s absolutely amazing.

Am I missing something? Have any of you tried it?

Thanks.

#2

“… I can throw away any service of my system, create a new one and just do a catch-up subscription to load data into my new service.”

…assuming the service does not have non-idempotent external side effects [email, cc processing, ifttt, etc].

#3

Yes, of course :). In those scenarios, I think I would just subscribe to the new events.

terça-feira, 23 de Junho de 2015 às 15:48:02 UTC+1, Kijana Woodard escreveu:

#4

I figured you had that covered, so I didn’t elaborate…“but for future readers”…

#5

Hi Bruno,

We mainly use it in this manner and are happy with it so far. Once projections are out of beta and competing consumers are in it will be even better for us.

Tom

#6

I think competing consumers are pretty much ready for reasonable use.
I know a few who are using now with reasonable load.

#7

Hi, if we used competing consumers rather than say NServiceBus, if we could not process an event at a subscriber what would the alternative to an error queue be? There are certain scenarios where we’ll want to retry a message x times before giving up until we’ve investigated the issue (e.g. if we are getting lots of errors from a 3rd party during peak traffic).

That’s the only aspect of the competing consumers approach over using NSB that I can’t see a clear alternative to without doing some bespoke work to provide equivalent functionality.

#8

Disposition Skip.

https://github.com/EventStore/EventStore/blob/release-v3.5.0/src/EventStore.ClientAPI/PersistentSubscriptionNakEventAction.cs

or just set retries etc on the subscription (general nak will go
through retries that are configured).

See also http://docs.geteventstore.com/dotnet-api/3.3.1/competing-consumers/
and http://docs.geteventstore.com/introduction/competing-consumers/

#9

Thanks Greg! That looks great.