In microservices, does it make sense to have separate code repositories for database migration scripts and API code?

Question

In accordance with bounded context, we have identified two microservices implementations, lets call them Service A and Service B respectively. Each of these microservices have different repositories (due to the benefits of Single Responsibility and better ownership). Now, each of these repositories use their own database schema (choice made for better separation of persistence and reduced maintenance of DB instances).

Earlier, we extracted the database migrations scripts (for continuous delivery) into a separate single repository (contains scripts for both Service A and Service B 's schemas) and run them under a single job under CI. Now as we tackle more stories, we have started facing some challenges, some of which are listed below:

• A change to a single schema triggers the build for the whole database and hence the downstream triggering of all the microservices, hence increasing our feedback time
• We are in general failing to achieve true continuous delivery, because a schema change also requires a respective change in the Service code and hence cautious efforts are taken to deploy both the PRs
• Moreover, there are some common tables like Users which needs to be used by both the schemas, which currently are being duplicated across both the schemas.

So my question/doubt is :

• Should we even separate the DB migrations repository according to the schemas, just like the Services.
• Should we even have separate repository for DB migrations scripts ? Should we club them within their respective Service repository code ?
• Should we extract the common tables further a level up and raise Domain Events for Eventual Consistency

Any pointers/advice would greatly help.Thanks.

Answer 1

You should consider keeping the migrations with the respective code repositories. Service A should have its own set of migrations independent of Service B. This will allow you to deploy Service A and migrate A's schema without any bearing on Service B.

Also, you should consider having no common tables. Common tables can have serious drawbacks. If Service A needs to modify User in a way that breaks Service B, you have created a distributed monolith.

---

UPDATE 1:

Building an audit log might not need strong referential integrity. You could consider soft foreign keys instead.

Much of how you design your microservices relies on the domain. If a User is an authenticated user, then you should first tackle the cross-cutting concern of authentication. You may choose for each microservice to require an authentication token such as a jwt to determine who the authenticated user is and whether or not they are authorized to perform some action. Then you could simply use the user's id in the audit log.

As for whether or not a user "falls under the service's bounded context", it likely does not. In other words, how are update against User bound to Service A? You probably do not consider the user to be subordinate to service A, nor would you want to update the user via actions against service A.