Data & Database Architecture - Moving from a monolithic architecture to microservices

I have a small question regarding a data architecture, and database.

We have a central database. It is connected to an API. This database was linked to a monolithic application that we are trying to break up into several services.

We have an API, we will call it "Api1". This API will manage different information, including provinces.

We also have another API, let's call it "Api2", which will manage data, like applications.

These applications are linked in database to a province. Until now, this Api2 was going to connect directly to the same database as the Api1. We want to put an end to this way of doing things, which is not the most optimal.

So, how do we keep this connection, and this referential integrity, with foreign keys from another database? Should we replicate the information from database 1 to database 2, or should we break the database link, and include an HTTP call to update this information from the API, and thus transform the "province_id" FK field to INT only?

My question is a bit complex, but the subject seems to me a bit complex, thanks in advance for your answers!

Christophe

There is no direct way to keep this referential integrity in such scenarios. There are several options available:-

1. Just remove the referential integrity and keep the id as INT only. We can opt the option if we are not using the App1 data directly in App2. It is just for reference only.
2. Replicate the data. Here we need to make sure that App1 data is Source of Truth and Replicate copy is read only.
3. Option 1 and one backend service that check if DB contain valid data.

As per my experience, mostly option 1 get used then option 2 and then 3. Also, the complexity level also increase in same order.