The Problem: Atomicity Across Boundaries

Why distributed transactions are hard

A single-database transaction gives you atomicity for free: wrap several writes in BEGIN ... COMMIT and either all of them apply or none do. The database engine owns all the data, so it can hold locks and roll back as one unit.

The moment a business operation spans two or more independent resources — say a Payments service on PostgreSQL and an Inventory service on MySQL — that guarantee disappears. There is no shared transaction log and no single component that can lock both systems and undo them together.

Consider placing an order: charge the customer, reserve stock, create a shipment. If the charge succeeds but the stock reservation fails, you have taken money for goods you cannot ship. We need a protocol that coordinates these independent steps so the system never lands in a half-applied state.

Two families of solutions

• Synchronous coordination — Two-Phase Commit (2PC): a coordinator forces all participants to agree before anyone commits. Strong consistency, but blocking and lock-heavy.
• Asynchronous compensation — Saga: break the work into local transactions, each with an undo step. Higher availability and looser coupling, but only eventual consistency.

Most modern microservice systems lean toward Sagas, but you must know 2PC cold — interviewers use it to test whether you understand why the industry moved away from it.