Skip to content

Latest commit

 

History

History
76 lines (64 loc) · 4.49 KB

Saga.md

File metadata and controls

76 lines (64 loc) · 4.49 KB
Raw

Saga

Motivation

Solution

Concepts

  • A sequence of asynchronous local transactions.
    • Each local transaction updates data within a single service.
    • A service publishes an asynchronous message when a local transaction completes. The message triggers the local transaction in the next service.
  • Use compensating transactions to rollback changes
    • Each local transaction has a compensating transaction to undo the change.
    • If one transaction fails, the saga needs to execute the compensating transaction of preceding transactions in reverse order.

Implementation

Types of Saga

  • Choreography
    • Concepts
      • Saga participants coordinate a saga operation by themselve.
      • A saga participant sends a message to the next saga participant triggering its local transaction.
    • Pros
      • Easy to implement.
      • Avoid the single point of failure of the saga orchestrator in the orchestration saga.
    • Cons
      • Risk of cyclic dependencies.
      • More difficult to understand (There is no a single place in the code that defines the saga).
  • Orchestration
    • Concepts
      • A saga orchestrator coordinates a saga operation with saga participants.
      • A saga orchestrator sends messages to saga participants telling them which transactions to perform.
    • Pros
      • Easy to understand (The code in orchestrator defines the saga).
      • Avoid the risk of cyclic dependencies.
      • Improves separation of the saga coordination logic (in the saga orchestrator) and the business logic (in saga participants).
    • Cons
      • Saga orchestrator has risk to become a single point of failure.
      • The risk of centralizing too much business logic in the orchestrator.

Pros & Cons

Pros

  • Maintains the data consistency of an application across multiple services.
  • Supports for long-lived transactions (Other microservices are not blocked if a microservice is running for a long time).

Cons

  • Increases the complexity of an application (difficult to design, debug, etc.).
  • Lack of isolation between transactions.

Consideration

Topic Consideration Possible Solution Options
Concurrency Multiple Sagas can run concurrently and cause the following problems:
  • Lost updates: One saga overwrites without reading changes made by another saga.
  • Dirty reads: A transaction or a saga reads the updates made by another saga that has not completed those updates.
  • Fuzzy/non-repeatable reads: Two different steps of a saga read the same data and get different results because another saga has made updates.
    		•
  • Semantic lock: An application-level lock.
  • Commutative updates: Design update operations to be executable in any order.
  • Pessimistic view: Reorder the steps of a saga to minimize business risk.
  • Reread value: Prevent dirty writes by rereading data to verify that it’s unchanged before overwriting it.
  • Version file: Record the updates to a record so that they can be reordered.
  • By value: Use each request’s business risk to dynamically select the concurrency mechanism.
    		•

    When To Use

    References