I'm doing the design of a shopping application, I've decided to use the micro services approach but in the way I'm designing the services I'm struggling with some decisions.
For example, I have a "shop-service" which will be the entry point for the user to start shopping and when calling this service we obviously need different information, being the products catalogue and inventory information the most important ones. These 2 other services are separate with each other and have their own databases.
The problem here is that "shop-service" makes no sense without these other 2, and for me it makes sense to communicate them through asynchronous calls for shop to wait both the catalogue information and the inventory information with the stock of each product and its location instead of using events, since it shouldn't be reactive if there's no movement in the catalogue or inventory services. (Note that I'm planning on putting events when something is changed to update the shop service with the newest information, but for this question's purpose think we assume there are no changes)
However, I feel like they are becoming too coupled even though it makes no sense to have a working shop without any of the other services working fine.
Would you happen to have any suggestion from an architectural point of view? Is it really bad to have 2 or 3 coupled micro services if they are very dependant with each other?