Eventstore for multiple microservices

Hello all,

I’m working on a project having multiple microservices (using one database schema per service) and intend to use the Axonframework.

Approach 1 is to have one eventstore per microservices.

Approach 2 is to have all microservices use a single eventstore.

Please I need suggestions on which approach to use and the possible merits and demerits, including how to configure axon in the case of the second approach.

NB: am using MYSQL database

Regards
Thanks

Hi Fonkeng,

I think answer to which approach to take really depends on what you’re building and what your requirements are.

If you’re creating several microservices in different contexts, in general I’d say it’s a lot cleaner for each service to have it’s own EventStore rather than a shared one.
It’s a better separation of your application environment in that sense I’d think.

You can however think of a microservice environment where you’ve got two (completely different) event-appending services and a third one which is only interested in the stream of events coming out of those two.
If the third service needs to have both event streams in time order, it could be beneficial to use the same EventStore for the first two microservices.

I however still think that, if it are two different applications, then they ideally shouldn’t be sharing one EventStore.

If you would go for approach two, configuration wise that would mean to use the same underlying database.
So in your case, you’d configure the Datasource for every Axon application to point to the same MYSQL database.

Hope this helps.

Cheers,

Steven

Hi,

I think the concept of Bounded Context (as referred to in Domain Driven Design) is important. You could have a number of microservice instances running within the same bounded context. They would share a language and really understand what certain events are about. There’s a big chance they are highly coupled in their language. Such services could share the same EventStore instance.

Services in different bounded contexts speak a different language. The way they represent events are different and they are not (or only weakly) coupled in language. Those services should not share an Event Store.

This is one of the topics in my “Messaging patterns for Event Driven Microservices” presentations. There is a recording of one of these presentations here: https://www.youtube.com/watch?v=3xDc4MEYuHI. The bounded context is discussed in the part where I start about “but how does this scale?”

Cheers,

Allard

Thanks for your quick reply, and also the the presentation link.

Thanks for the reply, it was indeed helpful.