Ch4. Managing transactions with sagas

4.1 Transaction management in a microservice architecture

• chanllenge: update data across database
  • legacy @transaction will introduce coupling to application
  • SAGA
    • only ACD, without isolation
    • conquer the absent isolation by introducing "data STATUS", control the isolation by developer

4.1.1 The need for distributed transactions in a microservice architecture

from monolith-app to microservices: the transaction maintains from single DB to multiple DB

4.1.2 The trouble with distributed transactions

• distributed transactions:

  • synchonous IPC:
    • reduce availibility, while today prefer availability rather than consistency.

• asynchro, loosely couple transaction: SAGA

4.1.3 Using the Saga pattern to maintain data consistency

• SAGA: A saga is a sequence of local transactions. Each local transaction updates data within a single service using the familiar ACID transaction frameworks and libraries mentioned earlier.
  • compensating transactions: because each local transaction commits its changes, a saga must be rolled back using compensating
    transactions.

AN EXAMPLE SAGA: THE CREATE ORDER SAGA

each txn trigger by the last success event, then publishes a message when a local txn completes.

• loosely coupled
• guarantees saga completes: That’s because if the recipient of a message is temporarily unavailable, the message broker buffers the message until it can be delivered.

SAGAS USE COMPENSATING TRANSACTIONS TO ROLL BACK CHANGES

• @transaction: undo by rollback
• SAGA: compensating transactions
  • 1. readonly query dont need to compensate
  • 2. always success steps don't need to compensate

compensate example
1 Order Service —Create an Order in an APPROVAL_PENDING state.
2 Consumer Service —Verify that the consumer can place an order.
3 Kitchen Service —Validate order details and create a Ticket in the CREATE
_PENDING state.
4 Accounting Service —Authorize consumer’s credit card, which fails.
5 Kitchen Service —Change the state of the Ticket to CREATE_REJECTED.
6 Order Service —Change the state of the Order to REJECTED.

4.2 Coordinating sagas: how to communicate across services

4.2.1 Choreography-based sagas

Distribute the decision making and sequencing among the saga participants. They primarily communicate by exchanging events.

• benefit:

  • simplicity: each services publishes events when CRUD business object, which is proper to simple SAGAs
  • loose coupleing

• drawbacks:

  • difficult to understand the business logic owing to scattered logic in each services
  • smelly cyclic dependency: might not be a problem, but smelly
  • tight coupling on subscription: Each saga participant needs to subscribe to all events that affect them.

4.2.2 Orchestration-based sagas

Centralize a saga’s coordination logic in a saga orchestrator class whose sole responsibility is to tell the saga participants what to do.

• command/async reply-style interaction: it sends a command message to a participant telling it what operation to perform. After the saga participant has performed the operation, it sends a reply message to the orchestrator.

MODELING SAGA ORCHESTRATORS AS STATE MACHINES

A state machine consists of a set of states and a set of transitions between states that are triggered by events.

SAGA ORCHESTRATION AND TRANSACTIONAL MESSAGING

a service must use transactional messaging in order to atomically update the database and publish messages.

• benefit:

  • simplicity: doesn’t introduce cyclic dependencies. the logic implemented in orchestrator.
  • less coupling: does not need to know about the events published by the saga participants.
  • Improves separation of concerns and simplifies the business logic

• drawbacks:

  • the risk of centralizing too much business logic in the orchestrator.

4.3 Handling the lack of isolation

because the updates made by each of a saga’s local transactions are immediately visible to other sagas once that transaction commits. This behavior can cause problems.

• anomalies: the outcome of executing sagas concurrently is different than if they were executed serially.

• countermeasures: deal with the lack of isolation

  • 1. implement isolation at the application level
  • 2. reduce the business risk of the lack of isolation

4.3.1 Overview of anomalies

• Lost updates: One saga overwrites without reading changes made by another saga.
• Dirty reads: A transaction or a saga reads the updates made by a saga that has not yet completed those updates.
• Fuzzy/nonrepeatable read: Two different steps of a saga read the same data and get different results because another saga has made updates.

4.3.2 Countermeasures for handling the lack of isolation

Semantic lock : An application-level lock

• a saga’s compensatable transaction sets a flag in any record that it creates or updates, indicating that the record isn’t committed and could potentially change. ex. APPROVAL_PENDING, REVISION_PENDING
• design how SAGA cope with:
  • retry:
    • simple implement, but need to implement the retry logic.
  • lock:
    • management the lock release and dead lock detection by developer.
      • dead lock action: performs a rollback of a saga to break a deadlock and re-execute it.

Commutative updates: Design update operations to be executable in any order

• Operations are commutative if they can be executed in any order.
• ex1. Account’s debit() and credit() operations are commutative (if you ignore overdraft checks).

Pessimistic view: Reorder the steps of a saga to minimize business risk

• reorders the steps of a saga to minimize business risk due to a dirty read.
• update the important data last (make the preStep are all updated):

reorder the Cancel Order Saga:
1.Order Service—Change the state of the Order to cancelled.
2.Delivery Service—Cancel the delivery.
3.Customer Service—Increase the available credit. -> the credit update last,
avoid the dirty read in the scenario of 3,2,1.

Reread value: Prevent dirty writes, lost updates by rereading data to verify that it’s unchanged before overwriting it

• Optimistic Offline Lock pattern: rereads a record before updating it, verifies that it’s unchanged, and then updates the record. If the record has changed, the saga aborts and possibly restarts.

Version file: Record the updates to a record so that they can be reordered

• records the operations that are performed on a record so that it can reorder them.

• It’s a way to turn noncommutative operations into commutative operations.

• ex. record the operations as they arrive and then execute them in the correct order.

it would first record the Cancel Authorization request. 
Then, when the Accounting Service receives the subsequent Authorize Card request, 
it would notice that it had already received the Cancel Authorization request 
and skip authorizing the credit card.

By value: Use each request’s business risk to dynamically select the concurrency mechanism.

• a strategy for selecting concurrency mechanisms(SAGAs or distributed txn) based on business risk.
  • SAGA: low risk
  • distributed txns: high risk. ex.txns of great amount money

4.4 The design of the Order Service and the Create Order Saga

4.4.1 The OrderService class

4.4.2 The implementation of the Create Order Saga

4.4.3 The OrderCommandHandlers class

4.4.4 The OrderServiceConfiguration class