I’m curious about the use of EventStoreDB in an event-driven microservice environment.
General consensus seems to be that a microservice will ideally will have its own ‘store’ and in this scenario the store will be EventStoreDB. However, if I want my other microservices to know about the domain events in another microservice then having them subscribed to the event store seems like an effective approach but suffers because all of my services rely on a single instance of EventStoreDB.
An alternative seems to be to have the microservice write to its private EventStoreDB and then to use a subscription to output the same events to an event bus for other microservices to consume if they’re interested.
The alternative approach feels like it may be quite clean albeit with some extra plumbing involved.
Any comments welcome.
2 Likes
In our development shop, we also considered both methods and ultimately decided on the former (i.e. using a single eventstore shared amongst multiple services). To separate the streams, we would add the microservice’s name before the name of the stream.
The decision came down to convenience vs cleaniness of the architecture. The latter approach would no doubt require extra plumbing. It’s much cleaner, but it’s also more complex and hard to understand (when event sourcing/microservice architecture is already complex for avg developers). Since our team didn’t have much experience with event sourcing, we decided the easier way out to improve adoption.
So the decision really depends on how things are for you!
On the other hand … if only EventStoreDB can support a “schema” type feature where it can be split itself into separate logical stores then we can perhaps the best of both worlds. It’ll be great if writing across these “schemas” is a native operation so that we don’t have to introduce extra plumbing.
This has been expressed in the past, but the EventStoreDB team had concerns about it due to dependencies/issues when it comes to clustering (iirc).
You can find the discussion here: Event Store
Btw I am also curious with how others in the community approach this!
-Stephen
Interesting topic,
We also had to make this decision. First, we started with one EventStore per micro-service. However, we moved to one shared EventStore for multiple reasons:
-
Our application supports multi-tenancy and for security and legal reasons, we wanted to have one EventStore per tenant. In this scenario, having one EventStore cluster per tenant and also per micro-service will make things quite complex. In addition, infrastructure cost can be also problematic.
-
For some cross-cutting functionality, it can be good to have access to events coming from different micro-services. For example, creating reports that use events projected from different micro-services. For cross-cutting stuff we could have used event-driven communication, but we will miss important capabilities, like time-travelling, replay of events, etc.
I will keep an eye on this topic as I would like to know how others are using EventStore in micro-services architecture.
2 Likes