CODEWITHSUNDEEP
microservicescqrsevent-sourcing
webish
webish

Reputation: 711

microservice based event store

Unfamiliar with all the details of domain driven design, would it make sense in a microservice architecture to think of each service as it's own domain and in turn build an event store per service?

Not totally sure what the trade-offs might be from a single monolithic event store for the entire system. For example, more difficulty replaying conditions in the system or debugging cross service dependencies.

Upvotes: 4

Views: 849

Answers (1)

Ruben Bartelink
Ruben Bartelink

Reputation: 61795

The key thing is to have an unambiguous single owner - i.e. if you share a store, that's fine, as long as only one service ever uses a given set of streams.

In NEventStore v5+ for example, this is codified in having a "bucket" be a subdivision within a store - each service gets an isolated set of state that way. Or one might do the same via multiple SCHEMAs in a SQL SB.

There are of course lots of good reasons to separate to the max too

  • you don't want to leave people open to temptation to read cross service
  • you want to enable the services to go Separate Ways - you don't want to have any infrastructure change for Service B to require a deploy of Service A
  • having a shared lib, which can go hand in hand with this view, is also a slipperly slope

It should be said that this concern is a general constraint in line with the autonomy tenet of microservices (and SOA before it)

Upvotes: 6

Related Questions