Let's say I have an application where I use multiple microservices. Two of them are USERS ( /users ) and CARS ( /cars ). Given a page called rental history ( /users/{id}/history ) which lists the rented car of the users.
Should I introduce an intermediary microservice RENTAL ( /rental ) which would query the other two microservices for the best architectural design ?
What is the correct design if I wanted to deploy this app under different brands, which means USERS database would be different , but the CARS database would be shared between the application ?
I would strongly suggest that you have a rental microservice to coordinate the process of renting (and returning etc.) a car by a user. Then the logic only appears in the rental service, not spread out over however many other services (counting UIs and such as services for this purpose).
I would actually question whether different brands would need fully-different user services, because there'd be a lot of common functionality. It might make sense to have a general user service with brand namespaces user IDs (so that, for instance, the rental service doesn't need to know about brands) and some brand-specific facades (e.g. to add the namespace to the IDs and maybe even handle things like frequent renter programs).