-
Notifications
You must be signed in to change notification settings - Fork 460
Glos saga
- A long-lived series of related transactions that are executed as a non-atomic unit.
- According to Greg Young, sagas should only contain routing logic, never business logic.
- Sagas respond to events and issue commands.
- Sagas may be implemented using State machines.
- Describes a flow of work across multiple Bounded contexts.
- A business process made up of a sequence of tasks.
- No central coordinator or state.
- Each task knows what the possible next tasks are: typically progress to the next task, or move to a compensation task.
- Tasks are chainable.
- Think in terms of a work-item with an attached routing slip.
- Coordinates a sequence of Events and Commands.
- Subscribes to events and issues commands. An event triggers a state change.
- Implemented as a State machine.
- Coordinates interactions between aggregates within a bounded context.
This paper from 1987 is the first definition of the Saga concept: Sagas.
The paper talks in terms of databases and database transactions but can be applied to other distributed scenarios.
Sagas are presented as an alternative to Long lived transactions (LLTs). An LLT wraps multiple short lived atomic transactions so if all of the short lived transactions succeed, so does the the LLT. LLTs cause problems because of the number and duration of locks required to guarantee transactional behavior. Examples of LLTs given in the paper include:
- Transactions to produce monthly statements at a bank.
- Transactions to process a claim at an insurance company.
- Booking a set of flights to make an itinerary.
An example from our domain could be:
- Purchasing seats at a conference. The individual transactional steps might be: store registrant details, reserve seats, make payment, commit on seats, assign attendees to seats.
The problems associated with LLTs may be alleviated by replacing the LLT with a saga. This is only appropriate if you can relax the constraint that the LLT must be a single atomic operation.
A saga replaces the atomic behavior of an LLT, with the notion that each individual transaction that makes up the LLT can be compensated for if it does not succeed. The compensation might be:
- Retry the step. For example, retry the payment step allowing the user to try a different card.
- Compensate for a step. For example, release the reservation on a previously reserved seat.
- Cancel the whole saga by compensating for all of the completed steps so far. For example, initiate a refund to a card, release all reservations, and then delete all registration data.
The saga implements a process that progresses towards some goal, for example a completed conference registration, so the saga defines what we can do at each step to continue to progress towards our goal. How we progress will depend on whether or not the current step succeeds or fails.
A saga is an approach to error management in a distributed system.