Shutterstock 1359882512

Distributed transaction in microservices made simple with saga in action

Microservices has grown popular across all enterprises and has largely influenced the software system development. A microservice may be subjected to a lot of dependencies that are challenging to maintain data consistency unlike the monolithic applications. The possibility of a seamless interdependent transaction across microservices is less due to this challenge.

For example, when policy information is updated in an insurance company’s system, the respective premium has to be updated in the premium microservice. Likewise, systems spanning multiple microservices become complex and difficult to operate and manage without proper communication.

Saga pattern comes into play to overcome this challenge. It is a sequence of transactional messages via event messages or API where each transaction updates data within a service. If there is a failure in any of the messages, saga invokes the compensation messages of the respective microservices. The initial transaction is made by an external request according to the operation of the system and then the successive step is initiated with the completion of the previous one.

You can implement saga transaction by two ways namely the event or choreography method and the command or orchestration method.

Event choreography is an easy way to implement saga as it has no central orchestration service. The services have to act and decide according to the events and compensation events of other services. For example. the initial service triggers the transaction and then publishes an event. Other services listens to execute their respective commands. If a failure happens, a compensative event is triggered. This distributed transaction concludes when there are no more events to be published after the last service execution. This method is

  • Easy to understand
  • Built at minimal effort
  • Fit for fewer transactions

While the major disadvantages are that it gets chaotic with more steps of transactions and to track them, also it adds cyclic dependencies among services.Orchestration method has a central coordinator that listens to various events emitted by the microservice local transaction. Based on the next event, it emits the next command/API call in different service. This method is

  • Easy to implement and test
  • The transaction complexity is linear
  • Resource complexity is less

However, this also has few disadvantages like focusing continuously on the logic of the orchestrator results in orchestration triggering services for operation and it increases the infrastructure complexity.

While both have pros and cons, it is usually better to adopt event choreography as it does not need any additional language that has the burden of governance and its performance is relatively higher than the orchestration method. Systems that use the choreography method are more flexible, lightly coupled and responsive, whereas the orchestrated systems are brittle and expensive.

Monitoring is an essential part of any system and to monitor each and every step and statement tends to be a low level and complex approach. Saga requires monitoring to be in par with the higher level abstraction of operations. It creates log comprising all the steps of execution from the beginning till the end in the order of execution. So, from the higher level, you can monitor the success rate with the number of defects logged and from the low level, you can monitor it through each statement.

Microservices and event based architecture complement each other. Projects that does not include saga pattern as a part of their design suffer from complexities. It is hence important to consider saga from the very beginning of the architecture. It helps dwindle these complexities due to the breakthroughs like monitoring and logging in the saga pattern. Designing or redesigning the architecture of IT systems for higher efficiency and optimizing on cost, maintenance and security is an essential part of any organization which Techcello is known for, as they provide services to architect microservices for your company.

 

Print Friendly

Jothi Rengarajan

Jothi serves as the Principal Architect of Techcello. She is responsible for the architecture and technical roadmap of Techcello; she plays consultative role for various customers of Techcello in architecting their products on top of Techcello. Prior to Techcello, Jothi worked with Aspire Systems as Technical architect, where she has architected and developed over 30+ SaaS/Multi-tenant products for global ISVs. Jothi is a prominent speaker on Cloud Technologies in various technical forums. She has 16+ years of software development experience. Jothi has bachelors in electronics and communication engineering.

More Posts - Website