One microservice should not call another microservice. This introduces coupling and is worse than the monolith – actually it creates a distributed monolith. Instead the services should use publish/subscribe event log to exchange data.
So do you mean in such systems there would no longer be a request-response communication model between the services? I am currently having a hard time imagining such kind of systems (especially for customer-facing SaaS apps), but it might just be because I haven't seen it yet.
Yes. The most important property of a well designed distributed architecture is that individual services are operationally completely independent of each other. That is if one service goes down the rest will continue to function and the system stays available. When services query each other monolith’s coupling is still there with the added ‘benefit’ of distribution faults. Why not stay with the monolith in first place?
For an infra composed of hundreds of very chatty microservices, most of which are interdependent, and where RMQ cannot handle the traffic, what do you recommend for handling eventing? We're using Kafka now, but curious for your thoughts.
One microservice should not call another microservice. This introduces coupling and is worse than the monolith – actually it creates a distributed monolith. Instead the services should use publish/subscribe event log to exchange data.
So do you mean in such systems there would no longer be a request-response communication model between the services? I am currently having a hard time imagining such kind of systems (especially for customer-facing SaaS apps), but it might just be because I haven't seen it yet.
Yes. The most important property of a well designed distributed architecture is that individual services are operationally completely independent of each other. That is if one service goes down the rest will continue to function and the system stays available. When services query each other monolith’s coupling is still there with the added ‘benefit’ of distribution faults. Why not stay with the monolith in first place?
For an infra composed of hundreds of very chatty microservices, most of which are interdependent, and where RMQ cannot handle the traffic, what do you recommend for handling eventing? We're using Kafka now, but curious for your thoughts.
We use Kafka too. For not so overwhelming loads and Ruby based services I would consider Eventide with PostgreSQL store.