Search code examples
microservicescqrsevent-sourcing

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.

Solution

  • 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)