Reputation: 1491
The problem I am having is Why we even need a pattern like SAGA (Asynchronous) or 2PC(Synchronous) to perform transactional inter-service communications between microservices ? .Because we can achieve that with a naming server. I mean let's think if a microservice goes down when it's in a middle of a transactional call so can't the naming server route that request to a different instance of the microservice required ? So then there won't be any unavailability among microservices .
Ex: A and B are microservices all those microservices are registered in a naming server like Eureka , A need B to complete the transaction by performing a inter-service communication. But unexpectedly B went down .So then naming server can route A's request to a different instance of B no .So where is that unavailability. So now why we need those patterns ?
Upvotes: 0
Views: 823
Reputation: 2297
It is not a matter of high availability but of data consistency, it is the same reason why we need transactions in a relational database. They are not needed only because the database connection could fail during a transaction, but because we want that the whole operation either succeed or fail. And this could include problems like constraints that are not met during inserts or updates.. etc.
And this problem could be applied to distributed transactions too. It could happen that you want that two operations in different microservices either succeed or fail. And if one of these operations fails, because the instances of that microservice are down, but also because an insert/update in the database fails due to any other reason, you want to revert the whole operation even the other call has succeeded and the changes have been committed.
And because of this, you need tools like saga pattern to implement compensating actions to revert the changes when this kind of things happen.
Upvotes: 1