
Ask HN: Microservices, Dependencies and Events - philometor
I’ve been doing a lot of googling regarding managing dependencies between microservices. We’re trying to move away from big monolithic app into micro-services in order to scale organizationally and be able to develop faster and with multiple teams working in parallel.<p>However, as we’re trying to functionally partition the monolith into the microservices, we see how intertwined business logic and data really is. This was not a problem when we were sitting on top of one big DB and were able to do big relational joins. But with microservices, this becomes a problem.<p>One solution is to make microservice-A go to 5-10 other microservices to get necessary data (this is equivalent of DB view with join). Another solution is to make microservice-A listen to events from 5-10 other services and populate local storage with relevant into (this is an equivalent of materialized view).
Either way, microservice-A is coupled with 5-10 other services, and if new info is needed in microservice-A, the some of the services that it depends upon might will need to be release prior to microservice-A. Please note that microservice-A is itself depended upon by other services. Bottom line, we end up with DISTRIBUTED dependency hell.<p>Many articles advocate for second solution – i.e. something along the lines of Event Sourcing, Choreography, etc.<p>I would appreciate any shared experiences, recommendations and insights.<p>Philometor.
======
he0001
I think it's interesting that you haven't got an answer from someone for this
question. What you are describing is the problem people tend to ignore when
describing microservices. The second solution won't help you with these
problems, just give you another set of equally hard problems you still have to
tackle.

