Saga Pattern | Distributed Transactions | Microservices

Summary

This video explains the complexities of distributed transactions in modern applications, particularly in microservices. It contrasts two key approaches: Two-Phase Commit (2PC) and Sagas. 2PC ensures strong consistency with synchronous communication, but it can introduce latency, deadlocks, and single points of failure. On the other hand, Sagas break down processes into smaller, independent transactions that communicate asynchronously, offering greater flexibility, scalability, and resilience to failures. The video uses a flight booking system as an example to illustrate these concepts, emphasizing how Sagas are ideal for long-running, complex transactions while 2PC is better for simpler, more atomic operations.

Takeaways

• 😀 Distributed transactions ensure that all operations in a transaction either succeed together or fail together, maintaining consistency across services or databases.
• 😀 Traditional databases use ACID properties (Atomicity, Consistency, Isolation, Durability) to ensure reliable transactions within a single system.
• 😀 Two-Phase Commit (2PC) is a protocol for distributed transactions, involving a prepare phase and a commit/rollback phase to ensure consistency across services.
• 😀 In the Two-Phase Commit protocol, if all participants agree to commit, the changes are finalized; if any participant disagrees, all changes are rolled back.
• 😀 2PC can introduce issues like latency, deadlocks, and reliance on a central coordinator, making it vulnerable to failures or delays.
• 😀 Sagas are an alternative to 2PC, offering flexibility by breaking down transactions into smaller, local operations, each with its own compensating action in case of failure.
• 😀 In an orchestrated Saga, a central Saga orchestrator controls the transaction flow and manages failure recovery, while in a choreographed Saga, services communicate directly through events.
• 😀 Sagas provide eventual consistency, which means that while individual steps may be atomic, the overall transaction may temporarily be in an inconsistent state before compensating actions are executed.
• 😀 Sagas are more resilient and flexible than 2PC, as they can adapt to failures by executing compensating transactions, reducing the risk of blocking the entire transaction.
• 😀 The main difference between 2PC and Sagas is that 2PC relies on synchronous communication and strong consistency, while Sagas use asynchronous communication and eventual consistency.
• 😀 2PC is best for simpler, short-lived transactions requiring strict consistency, while Sagas are ideal for long-running, complex transactions in microservices architectures, where scalability and flexibility are crucial.

Q & A

What is the main purpose of distributed transactions?

The main purpose of distributed transactions is to ensure that all operations within a transaction, across different services or databases, either succeed together or fail together, maintaining consistency and preventing data inconsistencies.

What does ACID stand for in the context of transactions?

ACID stands for Atomicity, Consistency, Isolation, and Durability. These are the properties that ensure that database transactions are processed reliably and maintain the integrity of the data.

How does the two-phase commit (2PC) protocol work?

The two-phase commit (2PC) protocol has two phases: the 'prepare' phase where participants check if they can commit the transaction, and the 'commit or rollback' phase where the coordinator either commits the transaction if all participants agree or rolls it back if any participant disagrees.

What is one of the key drawbacks of the 2PC protocol?

One key drawback of the 2PC protocol is that it can lead to system latency and reduced performance because services depend on each other and must wait for the coordinator's decision. It can also be susceptible to deadlock and require manual intervention if the coordinator fails.

How does Google Spanner mitigate the drawbacks of 2PC?

Google Spanner mitigates the drawbacks of 2PC by using the Paxos consensus algorithm, which ensures that each 2PC participant is highly available even if some nodes are down, reducing the risk of system failures during the commit process.

What is the difference between a saga and 2PC?

The main difference is that while 2PC uses synchronous communication and ensures strong atomicity, sagas use asynchronous communication and provide eventual consistency, allowing flexibility and recovery from failures through compensating transactions.

What is a choreographed saga?

A choreographed saga is a distributed transaction approach where services communicate directly through events, reacting to other services' events, without a central coordinator. Each service autonomously handles failures and compensates for actions taken.

How does an orchestrated saga differ from a choreographed saga?

In an orchestrated saga, a central coordinator (the Saga orchestrator) controls the flow of the transaction and sends commands to each service, while in a choreographed saga, there is no central coordinator, and services communicate and react autonomously through events.

Why is an orchestrated saga suitable for simpler use cases?

An orchestrated saga is suitable for simpler use cases because it provides centralized control and clear tracking of the process, making it easier to manage, especially when you need a clear audit trail and centralized decision-making.

When would you prefer to use a saga over 2PC?

You would prefer to use a saga over 2PC in scenarios involving long-running, complex transactions across multiple services where eventual consistency is acceptable, and flexibility, scalability, and failure recovery are important.