Lately I’m on medical leave and while I’m recovering I’m learning about microservice architecture, the cool way to have a distributed service architecture that allows us to scale service instances to work properly in case we have a business of hundreds of thousands or billions of concurrent users, such as those who have Facebook, google, amazon, netflix and other internet players. The fact is that these services usually use their own ACID data schema or at least ACD, that means managing a status machine that maintains the order of execution of each service and in case of having to rollback for such transactions, we have to control it. To do this we have two ways to manage it, a central object that makes the task of orchestrator, so you have to be responsible for invoking the different services, manage the different states through which the transaction passes distributed and rollback in case there is a problem and another called choreography, easier to see in which each service invokes the next when it is their turn.
A picture is better than a thousand words, in this case, we have a simple example of choreography with two services, UserService and EmailService, interconnected through a message broker, in this case, Kafka. There are also two fundamental actors, the Zuul gateway that we invoke to redirect to the requested service and the Eureka dynamic microservices registry that we use to control the state of life of the services:
Thank you Iskren Ivanov and Dreamix, i hope you don’t mind to use this png file.