Transactions in Distributed Systems

Saga Pattern

The distributed saga pattern is essential for managing transactions across multiple data stores in microservices. Joe Zack explains that each microservice must handle its own database, making it challenging to ensure that transactions are completed successfully across different systems 1. Alan Underwood adds that this pattern requires a sequence of local transactions, unlike traditional applications that rely on a single database 2. This complexity arises because each service must know where to listen for work and where to publish results, maintaining a loosely coupled system 3.

When you've got microservices that's spread out, you've got two different databases. And so when we had a single database that was asset compliant, it kind of had this basic pattern as a two phase commit where it basically ensures that things happen in the right order and they either happen fully or they don't.

--- Joe Zack

The saga pattern is a solution to this problem, allowing for distributed transactions without relying on a two-phase commit.

   

Orchestrator Logic

Orchestrating service logic in microservices centralizes transaction management, providing a "brain" to coordinate actions. Joe Zack describes how an orchestrator mediates between services, making it easier to trace and manage complex workflows 4. However, Alan Underwood notes that this approach introduces tight coupling, as the orchestrator must be aware of all services involved 5. Despite this, the orchestrator simplifies the process by modeling the entire transaction flow, making it easier to understand and manage 6.

The orchestrator has a brain and so it centralizes that logic. That's really the big difference. The choreography was all distributed logic.

--- Alan Underwood

This centralized approach contrasts with choreography, where each service independently manages its transactions.

   

Saga Completion

The saga completion process involves the client initiating a transaction and receiving updates until completion. Alan Underwood explains that the client must be informed when the saga completes, often through polling or webhooks 7. This process is more complex than traditional applications, as each service must communicate its status through message brokers 8. Joe Zack highlights that while choreography allows for loosely coupled services, it requires careful management of message queues and event handling 9.

The service sends back a response when the order id is created and submits an event via webhook or similar when the actual saga completes.

--- Joe Zack

This ensures that all parts of the transaction are completed successfully, even if some services fail.