Hi,
I’m about to start a project using event driven and microservices. Regarding the SQL Persistence I’m not clear if I need to configure a seperate database for each microservice/endpoint or if I should have a global database for all endpoints,
Thank you,
Pedro
This isn’t really a SQL Persistence question, it’s an architecture/microservices question. SQL Persistence is just an implementation detail.
As far as SQL Persistence is concerned, all endpoints will make their own tables for stuff, which DBAs can put on different drives or mess around with if need be even if they’re in the same DB. The important part is business data.
If you need to access a business data table from Endpoint A and you ALSO need to access it from Endpoint B, then those endpoints better be on the same database or you’ll start to get into cross-database transactions. This is where proper service boundaries really come into play, because an endpoint != a service/microservice.
If you really want to have microservices, then separated databases are crucial, because otherwise you’re just reintroducing coupling at the database level. But you can’t do that without proper service boundaries.
I recommend you watch the following 2 talks by my awesome coworkers @adamralph and @mauroservienti, to find out more about how to figure out your service boundaries, and how to deal with UI/ViewModel aspects in a microservices system without reintroducing coupling by doing request/response between the services.
Thank you for your reply, I was not asking about business databases, sorry if my question was not clear enough. For business databases we have a sepparate DB for each Microservice and use an event driven architecture to keep business data “in sync”. My question was regarding persisting data for NService bus features that require persistence (sagas, …) Persistence • NServiceBus • Particular Docs
Aha. Your NServiceBus persistence tables belong in the same database as your business data. Then you prevent the need for a cross-database transaction from within your message handlers. In fact, if you’re using the Outbox feature to guarantee consistency between your message operations and your business data changes, then you must be in the same database as your business data, as the Outbox depends upon tagging along on the local database transaction where you store your business data.