Saga

Advanced Database Management Systems

MCA
Context

 You have applied the Database per Service pattern. Each service has its own database.
Some business transactions, however, span multiple service so you need a mechanism
to implement transactions that span services.
 For example, let’s imagine that you are building an e-commerce store where customers
have a credit limit. The application must ensure that a new order will not exceed the
customer’s credit limit. Since Orders and Customers are in different databases owned
by different services the application cannot simply use a local ACID transaction.
Database per Service

 In this pattern, each microservice manages its own data. What this implies is
that no other microservice can access that data directly. Communication or
exchange of data can only happen using a set of well-defined APIs.
ACID

 ACID is a set of properties of database transactions intended to guarantee data

validity despite errors, power failures, and other mishaps. In the context of
databases, a sequence of database operations that satisfies the ACID
properties is called a transaction.
ACID Properties
Problem

 How to implement transactions that span services?

Forces

• 2PC(two-Phase Commit protocol) is not an option

2PC

 The two-phase commit protocol breaks a database commit into two phases to ensure

correctness and fault tolerance in a distributed database system.
The Protocol

Consider a transaction coordinator that manages the commits to database stores. As the
name suggests, the entire process is divided into two phases:
Prepare Phase

• After each database store (slave) has locally completed its transaction, it sends a
“DONE” message to the transaction coordinator. Once the coordinator receives this
message from all the slaves, it sends them a “PREPARE” message.
• Each slave responds to the “PREPARE” message by sending a “READY” message back
to the coordinator.
• If a slave responds with a “NOT READY” message or does not respond at all, then the
coordinator sends a global “ABORT” message to all the other slaves. Only upon
receiving an acknowledgment from all the slaves that the transaction has been aborted
does the coordinator consider the entire transaction aborted.
Commit Phase

• Once the transaction coordinator has received the “READY” message from all the
slaves, it sends a “COMMIT” message to all of them, which ​contains the details of the
transaction that needs to be stored in the databases.
• Each slave applies the transaction and returns a “DONE” acknowledgment message
back to the coordinator.
• The coordinator considers the entire transaction to be completed once it receives​a
“DONE” message from all the slaves.
Solution

 Implement each business transaction that spans multiple services is a saga. A saga is a
sequence of local transactions. Each local transaction updates the database and
publishes a message or event to trigger the next local transaction in the saga. If a local
transaction fails because it violates a business rule then the saga executes a series of
compensating transactions that undo the changes that were made by the preceding local
transactions.
Local Transaction

 Some software platforms do not provide transaction coordination as part of the

kernel operating system. When, instead, each resource manager involved is
seperately coordinating its own changes, and only its changes,
the transaction is known as a local transaction.
2PC=>Saga
There are two ways of coordination sagas:

• Choreography - each local transaction publishes domain events that trigger local
transactions in other services
• Orchestration - an orchestrator (object) tells the participants what local transactions to
execute
Choreography-based saga

An e-commerce application that uses this approach would create an order using a choreography-based saga that consists of the following steps:
1.The Order Service receives the POST /orders request and creates an Order in a PENDING state
2.It then emits an Order Created event
3.The Customer Service’s event handler attempts to reserve credit
4.It then emits an event indicating the outcome
5.The OrderService’s event handler either approves or rejects the Order
Orchestration-based saga

An e-commerce application that uses this approach would create an order using an orchestration-based saga that consists of the following steps:
1.The Order Service receives the POST /orders request and creates the Create Order saga orchestrator
2.The saga orchestrator creates an Order in the PENDING state
3.It then sends a Reserve Credit command to the Customer Service
4.The Customer Service attempts to reserve credit
5.It then sends back a reply message indicating the outcome
6.The saga orchestrator either approves or rejects the Order
Resulting context
This pattern has the following benefits:
• It enables an application to maintain data consistency across multiple services without using distributed
transactions
 This solution has the following drawbacks:
• The programming model is more complex. For example, a developer must design compensating transactions
that explicitly undo changes made earlier in a saga.
 There are also the following issues to address:
• In order to be reliable, a service must atomically update its database and publish a message/event. It cannot
use the traditional mechanism of a distributed transaction that spans the database and the message broker.
Instead, it must use one of the patterns listed below.
Related Patterns

• The Database per Service pattern creates the need for this pattern

• The following patterns are ways to atomically update state and publish
messages/events:
• Event sourcing
• Transactional Outbox
• A choreography-based saga can publish events using Aggregates and Domain Events
New Terms

 Event Sourcing
Event Sourcing is the persistence mechanism where each state transition for a
given entity is represented as a domain event that gets persisted to an event
database (event store).

 Transactional Outbox
Transactional Outbox is a pattern to reliably publish messages without the use of
distributed transactions. It has two parts , the Outbox and the message
dispatcher which work togethar to reliably persist state and publish messages.
 Aggregate
A graph of objects that can be treated as a unit.

 Domain Events
A service often needs to publish events when it updates its data. These events might be
needed. Alternatively, the service might participate in an choreography-based saga, which
uses events for coordination.
So Basically, Sagas

 Guarantee atomicity but not isolation

 Execute a sequence of transactions
 If all transactions succeed, then good (all)
 If any transaction fails, undo all previous in reverse order (none)
 Assumptions
 Compensations succeed (eventually) for the first several members of sequence
 Retries succeed for the last several
THANK YOU!!!