Spots

Two-Phase Commit Is a Trap: How Real Systems Do Distributed Transactions

Hello, I'm Maneshwar, and I'm building LiveReview — a blast-radius aware AI code review built for your business-critical systems. Star us to help devs discover the project, give it a try, and share your feedback to help improve the product. When you are first building an application, a transaction is the cheapest guarantee you will ever get. A customer places an order. You charge their card, reserve the inventory, write a ledger entry for accounting.

You wrap the whole thing in BEGIN and

You wrap the whole thing in BEGIN and COMMIT, and if any one of those writes falls over, the database quietly rewinds the other two. It is as if the order never happened. You probably wrote that code in four minutes and never thought about it again. What you were leaning on there are two of the ACID guarantees, doing unpaid labour on your behalf.

Atomicity. All three writes land, or none of

Atomicity. All three writes land, or none of them do. There is no universe where the card gets charged but the stock never gets reserved.

Isolation. While the transaction is in flight, nobody

Isolation. While the transaction is in flight, nobody else can see the half-finished middle. Another request checking the customer's balance will not catch a charge for an order that has not finished processing. You wrote the SQL. The database did the genuinely hard part, for free, and never asked for credit. Then you split the database, and the guarantee quietly leaves Traffic grows. Writes grow. That one box starts breathing heavily. So you do what everyone does. You shard, or you break the monolith into services and give each one its own database.

The details vary. The outcome is identical: your

The details vary. The outcome is identical: your data now lives on several independent machines that have never been introduced to each other. That one payment flow is now three separate operations against three separate databases. Card charged in the payments database. Stock reserved in the inventory database. Ledger entry recorded in accounting. There is no BEGIN big enough to cover all three, because none of them knows the others exist.

So when the card charge commits and the

So when the card charge commits and the inventory reservation then fails because the last unit just sold, nothing rolls back. That charge is already durable, on a different machine, in a database that has no idea an order died somewhere else.

At a few hundred orders a day, you

At a few hundred orders a day, you will see this maybe once and fix it by hand. At a few thousand transactions a second across distributed infrastructure, partial failure stops being an incident and starts being a Tuesday.

This whole shape of problem has a name

This whole shape of problem has a name: the distributed transaction. One logical operation spanning multiple independent databases or services, where every step needs to either succeed together or get cleaned up when something goes sideways.

The literature offers you two answers. The industry

The literature offers you two answers. The industry has very firmly picked one of them, and knowing why will save you a genuinely painful quarter. The textbook answer: two-phase commit Two-phase commit is the classic academic solution, formalised decades ago in the X/Open XA specification.

You introduce a new component, a coordinator, whose

You introduce a new component, a coordinator, whose entire job in life is to make every participant agree on the outcome before anybody makes anything permanent. It runs in two phases, which is where the name comes from.

News

Two-Phase Commit Is a Trap: How Real Systems Do Distributed Transactions

Hello, I'm Maneshwar, and I'm building LiveReview — a blast-radius aware AI code review built for your business-critical systems.

@spots #dev
Source: Dev.to
See more like this