Hi,
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?
Thanks,
Dan
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.
Greg
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
Cheers,
RR
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.