Let's say you have an app like Facebook, where each Post can be tagged with a Place. Now, the whole social app backend api (basically the whole client api) is built using nodejs + postgres. But the Places autocomplete is a custom API that is built in Golang for example.
Since the Places API is essentially based on a stateless DB (using postgres) cause it just stores information that is not to be manipulated by user, it makes sense to put it in its own micro-service.
So, it kinds of makes sense to have the following architecture :
Service A - the main client api / backend. In this service I can Like a post, follow a Friend, and post new Posts.
Service B - will have all the Places information and API. That means it will have tables with cities and countries, and expose an API to retrieve this information.
So if a user posts a new Post in London, Service A will handle this action and create a record in its db inside table "Posts" , where one of the columns will have the id of London (which sits in Service B's table).
Now, next time I want to Get that post, I will only have the place's id, but obviously we would want to show the information of that place (city name, country name, etc...).
It means that for an endpoint of "getPost(id = 2)" in Service A, we will have to join the Places tables from Service B. And that's the problem. Microservices should ideally not have any inter-communication between them that would constitute unwanted traffic load. Frankly, I'm not even sure how and if that's even technically plausible.
The alternatives would be to have a monorepo with project Places in Go, and the Main project in nodejs, with the same DB, or with 2 databases.
I am unable to weigh correctly the pros and cons and the probability of those alternatives, and would like to understand what is usually done in cases like this?
** P.S - Regardless of whether it would end up being Monorepo or micro-service architecture, I intend to use Docker + Kubernetes.