Should I use separate event stores? Please help!


I wonder
if you can help me.

I am in
discussions with one of the architects where I currently work. He is adamant
that we should have separate event stores per service. For various reasons, this does not sound
right to me.

Can I
please garner some opinions on the merits of using a single event store as
opposed to having an event store per service?



Its similar though not as strongly coupled to db per service. There are advantagea to a single db and logical separation vs physical. Physical separation also can have advantages (think scaling)

My guess is they come from a background where they did db per service and have followed as a dogma i would get into a discussion of the tradeoffs esp operational compkexity.

Also renember an event store has less coupkibg if shared.


So it is not as clear cut as I thought. Having watched a number of your
talks, my thinking was that, to fully utilise the power of event sourcing,
particularly running projections across domain contexts, is best served by
having a single event repository. After
all, the read-models, which often have greater scalability needs, can be scaled
out at a whim.

Anyway, thanks very much for your input. It is very much appreciated.

It also depends on the definition of “service”.

If a “service” is a noun factory - Product, User, Order. Then a single db will probably be easier. To get anything done, you’re doing a “mashup”.

If a “service” is a business capability, then separate dbs are easier to achieve [if needed] because the service can [must] live independently.

Few more things which we consider on the balance vs operational complexity
fault isolation per service

assign high performance hardware,

different replication strategies



Greg. I wonder if you can expand on "less coupling if shared"? I probably being dumb but I don't know what you mean by this.

Its more like sharing a queuing system than sharing a sql database.

Mainly, you’d have to do work to get cross service/tenant/stream projections.
With rdbms, you’d have to do work to prevent that.

There's a third option. Embedding event store in a service.