Hi everyone,
I was wondering what would be the best strategy when not using Axon Server when it comes to defining Jpa Event Stores, and here is what I mean.
When using axon-spring-boot-starter and you have jpa in your class path axon will pick that up and create appropriate tables in each database used by the corresponding microservice.
This causes the events emitted by each microservice to written to the database owned.
If each microservice was using the concept of "multiple databases" and defined the appropriate and common database for the event store, then a shared resource could be used, and all events would be written/read from a single DB
Should there be one event store shared between microservices that all events will be written/read, or should each microservice read/write events in its own database?
Thank you in advance for any shared insights.
George
Hi George,
In absence of using a centralized Event Store solution like Axon Server, sharing the database which contains the event tables is definitely an option you could go for.
There are pros and cons imaginable with this, let alone the puristic view that you shouldn’t share databases among microservices (also just an opinion if you’d ask me).
So, whether you go this route, is your choice of course.
I would however like to point out that sharing the event store database between identical versions of an application is fine, but sharing an event store between different types of applications is typically a bad idea.
In the latter situation you’d be mixing contexts within a single Event Store.
Doing so will make it that applications will be handling events from other applications it does not need to know anything about.
It’s better to share events between different bounded contexts concisely, through the means of an anti corruption layer for example.
Hope this gives you some background George.
Feel free to post follow up questions on this thread to further investigate the topic of course.
Cheers,
Steven
Hi Steven,
Thank you for the valuable information, I understand your point about sharing a database between microservices.
I am still researching about the right technologies to be used for my project, and I wanted a more educated opinion on this matter.
If I have any more questions, on this I will post something in this thread.
Thank you,
George
Τη Τετάρτη, 6 Μαρτίου 2019 - 3:24:09 μ.μ. UTC+2, ο χρήστης Steven van Beelen έγραψε:
Hi Giorgos,
I think it is Ok to share something between several instances of the same service (as Steven said). The reason for this is that a shared resource is another word of dependency. Especially, it is an operational dependency, which means that microservices should have similar lifecycles. This is obviously the case for multiple instances of the same service (doesn’t matter if they are created to reach high availability or high throughput), but normally doesn’t hold for different domains.
So be careful with that and try to avoid sharing in a cross-context case if possible. A really ugly use case for sharing is if you use the DB as a communication channel (one service writes and another reads), but I think in your scenario this is not the case.
What is the reason not to have each microservice to own its data? Is it only costs?
Kind regards,
Simon