Distributed Transactions

A single database gives you transactions for free. The moment a change spans two databases, two services, or two shards, you have to build that atomicity guarantee back yourself — and the two dominant answers, 2PC and sagas, sit at opposite ends of a consistency/availability tradeoff.

Two-phase commit

Every participant that votes yes must hold its locks and survive a crash with that promise durably logged — it cannot unilaterally decide to commit or abort afterward, only the coordinator's final word matters. That is exactly the problem: if the coordinator dies after collecting votes but before broadcasting the decision, every prepared participant is stuck holding locks, unable to proceed, waiting for a coordinator that may never come back. This is why 2PC is called a blocking protocol.

Sagas: local transactions plus compensation

interface SagaStep {
    void execute();
    void compensate();     // undo, called if a LATER step fails
}

void runSaga(List<SagaStep> steps) {
    Deque<SagaStep> completed = new ArrayDeque<>();
    try {
        for (SagaStep step : steps) {
            step.execute();
            completed.push(step);
        }
    } catch (Exception e) {
        while (!completed.isEmpty()) {
            completed.pop().compensate();   // unwind in reverse order
        }
        throw new SagaFailedException(e);
    }
}

A typical order-placement saga: reserve inventory, charge payment, schedule shipping. If shipping scheduling fails, the saga runs compensations in reverse — refund the payment, release the inventory reservation — rather than one giant lock held across all three services for the whole duration.