How to organize data transfer between microservices (if there is a common database)?

Question

API

Good afternoon, I need a couple of global tips on how to organize some processes.
There is such a draft structure.

It assumes that the front part is one big service, which has so-called "modules" - these are in fact other API services that expand the functionality of the system.
And the logic is that the service will have a single database of clients, so that there would be only one registration point for the client, and in addition, limits for each API will be stored in the common database (the number of requests per month, according to the tariff that the client of the system chooses).
The question is: how most correctly should API services communicate with each other so that they always have up-to-date data from a common database?, these are in fact the current limits and access rights.
PS Authorization will always go through a common database and a central API (it will be the entry point for all applications). But since each service has its own special differences and purposes, after authorization, each service uses its own database to store data. All this is assigned to the user.

Answer 1

You have a main (central) api, a main base and additional apis with their bases.
If you can directly access additional APIs from the front, then before making a request, make a request to the main database and check if there are rights and limits, if there are, then only in this case you form an appeal to an additional API.
Or make an invisible layer through the central API. That is, if a user needs something from an additional api service, then the request goes first to the central server, it checks whether there are rights and limits, and if everything is ok, then the request is forwarded further to the additional api.
In fact, this is almost the same thing, the difference is that in the second case, in the "eyes" of the front, you will have one single central api