Part 15: Microservices (Saga Pattern)

ALSO CHECK: Microservices Interview Questions And Answers

Observability
Every application relies on data and the success or failure of any business relies on efficient data management.

Data Management in a monolithic system can get pretty complex. However, it could be a completely different if you are using Microservices architecture.

Here are a couple of data management patterns for microservices:

• Database per Service - each service has its own private database
• Shared database - services share a database
• Saga - use sagas, which a sequences of local transactions, to maintain data consistency across services
• API Composition - implement queries by invoking the services that own the data and performing an in-memory join
• CQRS - implement queries by maintaining one or more materialized views that can be efficiently queried
• Domain event - publish an event whenever data changes
• Event sourcing - persist aggregates as a sequence of events

Saga Pattern

What is Saga? Well in layman's terms a Saga is a long story of heroic achievement or series of incidents.

In a technical term a saga is a sequence of local transactions, where each transaction updates data within a single service and publishes an event. The other services listen to that event and perform the next local transaction.

If one transaction fails for any reason, the saga also executes compensating transactions to undo the impact of the preceding transactions. In Saga pattern we commit multiple compensatory transactions at different stages ensuring to rollback when required.

Saga is one of the best way to ensure the consistency of the data in a distributed architecture 'without' having a single ACID transaction.

There are two ways to achieve sagas:
Orchestration: There is a Saga orchestrator (object) or a Saga Manager or Saga Execution Coordinator (SEC) which manages all the transactions and directs the participant services to execute local transactions based on events.

Choreography: In this approach we don't have a Saga Manager. Each service performs their transaction and publishes domain events, these events will triggers other services so that they can perform their transactions. Also, they may or not publish other events based on the situation.

Drawbacks of using Saga Pattern

• This approach can rapidly become confusing if you keep adding extra steps in your transaction as it is difficult to track which services listen to which events. It also might add a cyclic dependency between services as they have to subscribe to one another’s events.
• Testing would be tricky to implement using this design, in order to simulate the transaction behavior you should have all services running.
• Saga Execution Coordinator/Saga orchestrator easily manage Rollbacks, but it becomes more complex and becomes the core potion of the entire platform.

Important Tips while using Saga

• Do not let the participants to call SEC.
• Avoid cyclic dependencies between services.
• Avoid Synchronous Operations.
• Always create a Unique ID per request/transaction and make it flow through every local transactions. This will help traceability and troubleshooting.
• Log the request payloads for re-submission purpose.

-K Himaanshu Shuklaa..