I have an application made of several microservices with independent databases
So let's consider 2 microservices
Users and Documents
The users microservice manages the users and handles everything related to them and the documents microservice contains the document info, properties, file ....
Now each document belongs to a user and in the document database we have the
I know usually you should make a call to users to get the users data but imagine this scenario :
I have an api call that gets all the documents that are shared for a user, each document belongs to a user so if i fetch a thousand documents i have to make a thousand additional call to get the user data.
I thought of several options :
- have "common" tables like users replicated to all databases through a queue system (kafka for example) -> this will need to be maintained but gives the flexibility of having joins and foreign keys which makes it more performant
- Make an api route to take an array of ids and send back the data and handle this each time in the documents api to build back the object -> this will take additional work each time and less performance but it will be the "clean" way to work with microservices
- link each microservice to a "common" database in addition to its own database for easy access -> this is a shortcut to replicate tables but won't solve the issue and we can't join on it using ORMs
I imagine it's a common case, but I can't see anywhere what's the best practice for this use case