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?
Is it really bad to have 2 or 3 coupled micro services if they are very dependant with each other?
Yes, and your system it trying to tell you something.
It's not obvious at the beginning of design what the boundaries of your microservices should be.
When you separate two service endpoints into separate microservices you often need to implement asynchronous communication or data replication between them.
At some point the complexity and performance cost of that outweighs the benefit of having a separately deployed microservice.
This is how you group operations into microservices. Strong coupling within a microservice, and loose coupling between microservices.
An over-atomized, over-distributed microservice application is infinitely worse than a monolith.