Ilkka Seppälä
4108f86177
* Changed database implementation. Removed static objects. * Fix Logs * Fix 40 errors from checkstyle plugin run. 139 left)) * Fix CacheStore errors from checkstyle plugin 107 left * Fix last errors in checkstyle. * Fix sonar issues * Fix issues in VALIDATE phase * Fix Bug with mongo connection. Used "Try with resources" * Add test * Added docker-compose for mongo db. MongoDb db work fixed. * Provided missing tests * Comments to start Application with mongo. * Fix some broken links * Remove extra space * Update filename * Fix some links in localization folders * Fix link * Update frontmatters * Work on patterns index page * Work on index page * Fixes according PR comments. Mainly Readme edits. * fix frontmatter * add missing png * Update pattern index.md * Add index.md for Chinese translation * update image paths * update circuit breaker image paths * Update image paths for localizations * add generated puml * Add missing image * Update img file extensions * Update the rest of the EN and ZH patterns to conform with the new website Co-authored-by: Victor Zalevskii <zvictormail@gmail.com>
title, category, language, tags
| title | category | language | tags | |
|---|---|---|---|---|
| Saga | Concurrency | en |
|
Also known as
This pattern has a similar goal with two-phase commit (XA transaction)
Intent
This pattern is used in distributed services to perform a group of operations atomically. This is an analog of transaction in a database but in terms of microservices architecture this is executed in a distributed environment
Explanation
A saga is a sequence of local transactions in a certain context. If one transaction fails for some reason, the saga executes compensating transactions(rollbacks) to undo the impact of the preceding transactions. There are two types of Saga:
-
Choreography-Based Saga. In this approach, there is no central orchestrator. Each service participating in the Saga performs their transaction and publish events. The other services act upon those events and perform their transactions. Also, they may or not publish other events based on the situation.
-
Orchestration-Based Saga In this approach, there is a Saga orchestrator that manages all the transactions and directs the participant services to execute local transactions based on events. This orchestrator can also be though of as a Saga Manager.
Class diagram
Applicability
Use the Saga pattern, if:
- you need to perform a group of operations related to different microservices atomically
- you need to rollback changes in different places in case of failure one of the operation
- you need to take care of data consistency in different places including different databases
- you can not use 2PC(two phase commit)