2 ms·

This only works for the simplest cases. If the two microservices must share data and direct calls (API calls) are not allowed (because they make your services h

by dakiol 6y ago

This only works for the simplest cases. If the two microservices must share data and direct calls (API calls) are not allowed (because they make your services highly coupled to each other to the point where if one of them ia down, then the other cannot work properly, or simply because your use case cannot tolerate the latency overhead) then each service must 1) replicate the data needed locally by listening to interesting events of the other service and b) emit interesting events so that the other service can update its local db. In other words, async communication. While this let's you scale up teams, it's a huge overhead. So, unless you have over, let's say, 500 devs, it's not worth it.

corpMaverick 6y ago
> This only works for the simplest cases. If the two microservices must share data and direct calls (API calls) are not allowed Actually, one assumption is that the microservices don't share data. Only API (Rest, SOAP, GraphQL, etc) calls are allowed. And the boundaries are created minimizing the coupling between microservices. > While this let's you scale up teams, it's a huge overhead. So, unless you have over, let's say, 500 devs, it's not worth it. As opposed to Monolith ? I think you will have problems collaborating in a Monolith at around 30 devs. What I am opposing is the idea that you can have 30 devs and 50 microservices. Which I have seen in real life.