tags: #publish links: [[Software Architecture]] created: 2020-10-27 Tue --- # Saga An architecture pattern to get the effect of distributed transactions to achieve (eventual) consistency across multiple services, without actually having distributed transactions. https://microservices.io/patterns/data/saga.html - No **2-Phase Commit** - Implement multi-service transactions as a series of one-service transactions; if one fails, execute a series of "undo" transactions instead. ## Choreography-based *Each dancer queues the next one* Each local transaction publishes events to trigger the next transaction in the next service. e.g. Order -> order created event -> reserve credit -> publish success or fail event -> update order status Choreography gets messy / hard-to-track quickly if there's multiple operations/participants. ## Orchestration-based *Conductor makes the music flow* A central orchestrator tells each participant which transactions to execute. e.g. Order -> order orchestrator makes a call to reserve credit -> returns success or fail -> orchestrator decides what to do to order status Complexity is easier to manage than with choreography because it's all in one place. ## Disadvantages of Saga - Need to design undo/rollback transactions - potentially hard if they could interfere - The atomic operations in each service must both atomically update datastore *and* publish events: - Event Sourcing - [[Transactional Outbox]]