Although I have found moving into the Microservice technology to be very compelling and rewarding in many ways, one challenge I came across is when you traditionally would write a query based on JPA that may join a Customer with an Address (this is just an example).
The problem is, we need to return many customer records (say 100 at a time) where each Address is assigned to a Customer (let's assume one to one relationship).
Using a Join and JPA solves this problem very easily, but in Microservices, essentially we would need 2 Microservices, one for Customer, one for Address. The problem is, we may first fetch the Customer records but how do we return all of the Address records that relate to each Customer since the Address records have a dependency on the Customer being queried?
I don't think we can use a single query in each Microservice that would return every Address unless we use every Customer ID from the first result as that would be horrible in so many ways.
Since the criteria for the query may not pertain to both Microservices (example: if we search by last name), we don't have a single criteria value we can use in both Microservices that would allow us to easily map the data together in the gateway.
So what do we do?
If you found yourself in a position where you are often required to return large, report-style, lists (for want of a better term), then perhaps the answer is in providing a "Search" microservice.
If the two entities definitely do not belong together (you could argue from your example, that Address is simply a property of Customer and so what are they doing in two different places), then maintaining some kind of denormalised, or ViewModel-friendly, representation of both entities together would seem reasonable.