Distributed Systems Design Pattern: Two-Phase Commit (2PC) for Transaction Consistency [Banking Multi-Account Transfers Use?Case]

The Two-Phase Commit (2PC) protocol is a fundamental distributed systems design pattern that ensures atomicity in transactions across multiple nodes. It enables consistent updates in distributed databases, even in the presence of node failures, by coordinating between participants using a coordinator node.

In this article, we’ll explore how 2PC works, its application in banking systems, and its practical trade-offs, focusing on the use case of multi-account money transfers.

The Problem:?

In distributed databases, transactions involving multiple nodes can face challenges in ensuring consistency. For example:

• Partial Updates: One node completes the transaction, while another fails, leaving the system in an inconsistent state.
• Network Failures: Delays or lost messages can disrupt the transaction’s atomicity.
• Concurrency Issues: Simultaneous transactions might violate business constraints, like overdrawing an account.

Example Problem?Scenario

In a banking system, transferring $1,000 from Account A (Node 1) to Account B (Node 2) requires both accounts to remain consistent. If Node 1 successfully debits Account A but Node 2 fails to credit Account B, the system ends up with inconsistent account balances, violating atomicity.

Two-Phase Commit Protocol: How It?Works

The Two-Phase Commit Protocol addresses these issues by ensuring that all participating nodes either commit or abort a transaction together. It achieves this in two distinct phases:

Phase 1:?Prepare

1. The Transaction Coordinator sends a “Prepare” request to all participating nodes.
2. Each node validates the transaction (e.g., checking constraints like sufficient balance).
3. Nodes respond with either a “Yes” (ready to commit) or “No” (abort).

Phase 2: Commit or?Abort

1. If all nodes vote “Yes,” the coordinator sends a “Commit” message, and all nodes apply the transaction.
2. If any node votes “No,” the coordinator sends an “Abort” message, rolling back any changes.

Problem Context

Let’s revisit the banking use case:

Prepare Phase:

• Node 1 prepares to debit $1,000 from Account A and logs the operation.
• Node 2 prepares to credit $1,000 to Account B and logs the operation.
• Both nodes validate constraints (e.g., ensuring sufficient balance in Account A).

Commit Phase:

• If both nodes respond positively, the coordinator instructs them to commit.
• If either node fails validation, the transaction is aborted, and any changes are rolled back.

Fault Recovery in Two-Phase Commit

What happens when failures occur?

• If a participant node crashes during the Prepare Phase, the coordinator aborts the transaction.
• If the coordinator crashes after sending a “Prepare” message but before deciding to commit or abort, the nodes enter an uncertain state until the coordinator recovers.
• A Replication Log ensures that the coordinator’s decision can be recovered and replayed after a crash.

Practical Considerations & Trade-Offs

Advantages:

1. Strong Consistency: Ensures all-or-nothing outcomes for transactions.
2. Coordination: Maintains atomicity across distributed nodes.
3. Error Handling: Logs allow recovery after failures.

Challenges:

1. Blocking: Nodes remain in uncertain states if the coordinator crashes.
2. Network Overhead: Requires multiple message exchanges.
3. Latency: Transaction delays are due to the preparation and commit phases.

The Two-Phase Commit Protocol is a robust solution for achieving transactional consistency in distributed systems. It ensures atomicity and consistency, making it ideal for critical applications like banking, where even minor inconsistencies can have significant consequences.

By coordinating between participant nodes and enforcing consensus, 2PC eliminates the risk of partial updates, providing a foundation for reliable distributed transactions.

#BeIndispensable #DistributedSystems