Why Distributed transactions and 2PC in DBMS Theory? - Purpose & Use Cases

The Big Idea

What if your money transfer got lost halfway because systems didn't talk to each other?

The Scenario

Imagine you are managing money transfers between two different bank accounts located in separate systems. You try to update both accounts manually, one after the other, without any coordination.

The Problem

This manual approach is risky because if one update succeeds and the other fails, the money could disappear or be duplicated. It's slow and error-prone since there's no guarantee both systems agree on the changes.

The Solution

Distributed transactions with Two-Phase Commit (2PC) solve this by coordinating all systems to agree before making changes permanent. This ensures either all updates happen together or none do, keeping data consistent.

Before vs After

✗ Before

update accountA set balance = balance - 100;
update accountB set balance = balance + 100;

✓ After

begin transaction;
prepare transaction;
commit transaction if all agree;
rollback if any fail;

What It Enables

It enables reliable and consistent updates across multiple systems, even when they are separate and independent.

Real Life Example

When you transfer money between banks, distributed transactions ensure your money leaves one account and appears in the other without loss or duplication.

Key Takeaways

Manual updates across systems can cause errors and data loss.

Distributed transactions coordinate all systems to agree before committing.

Two-Phase Commit ensures all-or-nothing updates for consistency.