Profile Photo

Saga Pattern

Created on: Sep 25, 2024

In a microservice architecture we use one database per microservice. This is done to promote decoupling, scalability and independence between services.

If we use use shared db for multiple service,

  1. we can't increase db capacity for individual basis.
  2. Tight coupling: Sharing a database creates tight coupling between services

So database per service is preferred in microservice ensuring independence in scaling, schema design, and operations like deletion or updates. There are some major challenges in database per services.

  1. Handling Transactions Across Multiple Services
  2. Cross-Service Queries: We can't don't join operation across db in multiple service. This leads to the execution of complex query.

To solve above problem, there are two design pattern

  1. SAGA
  2. CQRS

SAGA ( Sequence of local transactions )

A saga is a sequence of transaction that update each service and publish a message or event to trigger next transaction. If a step fails, saga executes compensating transactions that neutralize the previous transaction.

There are two approaches for SAGA pattern

  1. Choreography
  2. Orchestration

Choreography:

Choreography is a way to coordinate sagas where participants exchange events without a central point of control.

For example we have a e-commerce application, where customer places a order. Order services receives the order from customer and publishes a event. Inventory service subscribe to these event. When message is received, it check for item in store. If available it will reserve the number of item and trigger another event which is subscribed by payment service. After receiving the message, payment process the payment. If payment is success it will make entry in db and trigger event for another microservice. If it fails, firstly local transaction will be roll backed. Then payment service will trigger failure event which will be subscribed by inventory service. Inventory service will rollback local transaction. Similarly order service receives failure event and mark the order failed or other action based on requirement.

Benefit:

  1. Good for simple workflows that require few participants and don't need a coordination logic.
  2. Doesn't require additional service implementation and maintenance.
  3. Doesn't introduce a single point of failure, since the responsibilities are distributed across the saga participants.

Drawbacks

  1. Workflow can be confusing when adding new step.
  2. There is a risk of cyclic dependency between saga participants.
  3. Integration testing is difficult.

Orchestration

Orchestration is a way to coordinate sagas where a centralized controller tells the saga participants what local transactions to execute.

In the same example for choreography, order service receives the request and trigger the orchestrator to handle the next step. orchestrator starts by sending request to inventory to check item is available. Inventory service check the inventory and sends back either a confirmation or an out-of-stock notification. If items are in stock, the orchestrator sends a request to the Payment Service to process the payment. Similarly local transaction happens.

Benefits:

  1. Centralized control: The orchestrator handles the complex workflow making it easier to manage process flow.
  2. Error handling: The orchestrator can manage retries, rollbacks, or compensating actions if something goes wrong
  3. Don't introduce cyclic dependency

Reference