Internal (within a micro-service) & external eventstore

EventStoreDB
1

Hi,
We’re implementing a micro service-based application where each micro service might be implemented using Event sourcing. We are considering whether using one event store that is shared between micro services or using one store per service, and an extra one for cross-service communication. The later choice is much clearer, and provides separation of concern, but requires repetitive trivial actions of reading the internal events and publishing external events, which seems not very pragmatic. Could you please give us some comments on this ?

2

Why not a service bus?

3

All of these approaches are legitimate. You’ve already enumerated the tradeoffs.

Having private/public streams comes with the tradeoffs you’ve mentioned, so you need to figure out whether it’s the only option you have. Can you establish circles of trust with regards to streams and services, ie: a group of “related” services can read each others’ streams, but unrelated or “distant” services cannot?

You should also take into consideration that when you’re talking about having one installation of the store per service that you’re actually talking about having one CLUSTER of stores per service, with all of the operations implications that entails.

You might also explore using replies between “distant” services where you don’t want to expose streams outside that circle of trust. That’s not something that the store provides explicitly. It’s just a technique where a reply stream name is included with the original command.

-Scott

4

Hi Scott.
Yes, I meant “installation” - the whole CLUSTER.

I haven’t thought about “circles trust” and reply stream names, which sound interesting to me. I’ll do investigate on that.

Thank you very much for your very useful information.

5

We decided to have one cluster for production across all micro-services. Why? The amount of effort to maintain the cluster.

Also we are using http://nats.io/ for a bus. For us it its the right tool for the specific job its doing.

6

While with a database I generally prefer a db per service I feel less
so about sharing an event store. One strategy worth looking at for
sharing is by setting ACLs to prevent services from writing to the
same streams.

7

Thanks Greg & Bryan,
In our situation I don’t see any problem applying the strategy you suggested.

And yes, the effort to maintain the cluster is considerable.

Thieu.