What the Two‑Generals Problem Reveals About Distributed Transactions

Preface

After a few months since the last update, the author resumes the series on distributed systems, recalling the previous discussion on the best way to open CAP and introducing the topic of distributed transactions.

The Two‑Generals Problem

A classic computer‑science story is presented: two white armies surround a black army in a valley. Individually each white force is weaker, but together they outnumber the black army. They must coordinate an attack by sending messages across the valley, risking capture.

Scenarios

Scenario 1 : The messenger from the left side is captured; the right side never receives the attack order.

Scenario 2 : The left side delivers the order, but the reply from the right side is captured; the left side does not know whether the right side received the command.

Scenario 3 : Both the message and the reply succeed; the white armies win.

Battle‑field Review

Unstable communication channels resemble the Send/Ack process in systems; any failure makes the whole transaction abort, mirroring the atomicity requirement of CAP.

If a message or its acknowledgment fails, the commander must wait for a timeout and retry, but retries must be bounded to avoid resource exhaustion and system collapse.

Sending multiple parallel messages from one side does not change the outcome for the other side, illustrating system idempotence.

The problem is analogous to TCP’s three‑way handshake; the article asks why three steps are needed instead of two.

Local Transactions

Local transactions refer to traditional ACID transactions taught in database courses. Using the supermarket apple‑checkout analogy, if the checkout system crashes after the items are selected, the transaction fails and no data changes, exemplifying a local transaction.

Distributed Transactions

When a single‑database system reaches performance limits and is split into multiple physical instances, cross‑database operations introduce network latency and the need for distributed transactions.

For example, a coupon table (A) and a payment table (B) that were once in the same database now reside on different instances; a purchase that uses both must be coordinated across the two databases.

Key Roles

Resource Manager (RM) : the participant that holds a specific resource such as a database or service.

Transaction Manager (TM) : the global coordinator that manages multiple RMs, ensuring they commit or roll back together to achieve global ACID properties.

Differences Between Local and Distributed Transactions

Local transactions involve a single node with no network latency, so they avoid consistency problems inherent to distributed systems. Distributed transactions require RPC communication, face timeouts and failures, and must handle coordination across nodes.

An analogy: a solo project works without coordination, while a multi‑person project needs a coordinator (TM) to keep everyone aligned, similar to a distributed system.

Distributed Transaction Scenarios

Resource‑Driven : Multiple data resources are spread across nodes, leading to distributed transaction needs.

Service‑Dependency‑Driven : Complex microservice architectures where services depend on each other’s data, creating distributed transaction scenarios.

Hybrid‑Driven : Both data distribution and service dependencies coexist, leading to mixed transaction patterns.

Classification of Distributed Transactions

Implementation approaches fall into two categories:

Rigid Transactions : Provide strong consistency without requiring business changes; suitable for short‑lived transactions but limit concurrency.

Flexible Transactions : Require business adaptation, operate asynchronously, achieve eventual consistency, and support high‑throughput long‑running transactions.

From a CAP perspective, rigid transactions correspond to CA systems (strict ACID), while flexible transactions align with BASE systems (eventual consistency).