How to transfer everything to microservices and make a sustainable architecture?

Question

Software design

Hello. I'm trying to figure out how to make a fault-tolerant architecture on microservices more correctly. Suppose we have some kind of chain of independent services within the system that communicate with each other via API. What is the correct way to rollback a transaction if the chain of microservice requests, the so-called "saga", has failed? Do a separate action to roll back to the previous service? But such a scheme will not work, since initially the services in which the operation was successful do not know that some next service failed. For example, we have two services, the first is sending the user's password to the mail, and the second is the user's registration. If we have a microservice with user registration, then the first service will send the password in any case, but will not know what "lies" a second service without directly requesting it. There is another idea, if there is a chain of microservices, then all requests should be made through MQ RPC. And in this way we can make a branched system of sagas in which there will be constant monitoring of requests from other services, and if one of them fails, then roll back, or simply do nothing. But then the question arises, what to do with "unreliable" microservices that are located on the other side and that you don't want to include in the general MQ pool, or does the communication between them occur according to other scenarios? Do an additional anticorruption layer for such cases? I will be glad to your ideas. in which there will be constant monitoring of requests from other services, and if one of them fails, then rollback, or simply do nothing. But then the question arises, what to do with "unreliable" microservices that are located on the other side and that you don't want to include in the general MQ pool, or does the communication between them occur according to other scenarios? Do an additional anticorruption layer for such cases? I will be glad to your ideas. in which there will be constant monitoring of requests from other services, and if one of them fails, then rollback, or simply do nothing. But then the question arises, what to do with "unreliable" microservices that are located on the other side and that you don't want to include in the general MQ pool, or does the communication between them occur according to other scenarios? Do an additional anticorruption layer for such cases? I will be glad to your ideas. which are located on the other side and which you do not want to include in the general MQ pool, or does the communication between them occur according to other scenarios? Do an additional anticorruption layer for such cases? I will be glad to your ideas. which are located on the other side and which you do not want to include in the general MQ pool, or does the communication between them occur according to other scenarios? Do an additional anticorruption layer for such cases? I will be glad to your ideas.

Answer 1

So, a lot of things are mixed, let's sort it out. We have: - X different services with different
interfaces
- lack of transactionality
- no guarantee of service availability - the need
to control it
all I'm not very aware of what is now on-prem solutions, but from my world there is AWS StepFunctions. We are looking for analogues for our enva - if there are no ready-made solutions, then you will have to build your event architecture on queues with brokers and mediators
- for the problem of unavailability of services, you will have to use exponential backoff or exponential retry. Again, in my world, AWS SNS decides.
In general, in the days before the clouds, I did this on RabbitMQ and ingenuity, but with any such systems, the problem of contract validation arises, so it’s up to you to decide which part to transfer the complexity to.