Imagine you are sending money to your friend using a mobile banking app. Your bank takes ₹500 out of your account, and your friend’s bank puts ₹500 into their account. This looks like one simple action — “send money” — but it is really two separate actions happening in two separate places: your bank’s database and your friend’s bank’s database.

Now here is the big question: what happens if your bank successfully removes the money, but your friend’s bank crashes right before it can add the money? Your ₹500 has vanished into thin air. This exact problem — keeping multiple, separate systems in agreement even when things go wrong — is what a distributed transaction is designed to solve.

A distributed transaction simply means: this same “all or nothing” promise, but now the smaller promises are scattered across different computers, different databases, or even different companies, often connected only by a slow and unreliable network.

A Short History

In the early days of computing (1970s–1980s), almost all applications used a single database running on a single machine. Keeping data consistent was relatively easy because everything lived in one place, protected by one piece of software.

As companies grew, they started splitting their systems: one database for orders, one for payments, one for inventory — sometimes even in different countries. Researchers at IBM and other labs in the late 1970s designed a protocol called Two‑Phase Commit (2PC) to let multiple databases agree on a transaction together. This became part of a standard called X/Open XA in the early 1990s, which many enterprise databases and message queues still support today.

Then came the internet‑scale era: Amazon, Google, Netflix, and Uber began building systems so large that a single database could no longer handle the traffic. This gave birth to microservices — hundreds or thousands of small, independent services, each with its own database. Classic 2PC turned out to be too slow and too fragile for this new world, so engineers invented lighter‑weight patterns like Sagas, TCC (Try‑Confirm/Cancel), and modern consensus algorithms like Paxos and Raft. This tutorial will teach you all of these, from the ground up.

Fig 1.1 — How distributed‑transaction techniques evolved over 50 years.

Why can’t we just use a normal, simple transaction for everything? Let’s understand the problem step by step, starting with what works well on a single machine.

2.1 The World Before Distribution: Local Transactions

When all your data lives in one database, that database gives you a beautiful guarantee called ACID:

2.2 The World After Distribution: The Problem Appears

Now split your system into multiple services, each owning its own database:

• Order Service → Order Database
• Payment Service → Payment Database
• Inventory Service → Inventory Database
• Shipping Service → Shipping Database

Placing an order now requires four different databases, on four different machines, possibly in four different data centers, to all agree. A normal ACID transaction cannot span across separate databases or separate network machines — there’s no shared lock manager, no shared transaction log, and the network between them can fail, slow down, or get partitioned at any moment.

2.3 The Core Challenges

This is exactly the motivation for distributed transactions: we need techniques and protocols that let independent systems, connected by an unreliable network, still reach agreement — either “everything succeeded” or “everything was undone” — without needing to be one giant database.

Before we go deeper, let’s pin down the vocabulary that will show up in every remaining section.

3.1 What Exactly Is a Distributed Transaction?

A distributed transaction is a sequence of operations performed across two or more independent, networked resources (databases, message queues, services, or systems) that must be completed with the same all‑or‑nothing guarantee as a normal transaction — even though no single computer controls all the resources.

3.2 Key Vocabulary You Must Know

3.3 ACID vs. BASE

Distributed systems often trade strict ACID guarantees for a looser, more available model called BASE.

3.4 Types of Distributed Transactions

• Homogeneous: all participants use the same type of database (e.g. all MySQL databases replicated across regions).
• Heterogeneous: participants use different technologies (e.g. PostgreSQL + Kafka + a REST‑based payment gateway).
• Short‑lived (ACID‑style, 2PC): completes in milliseconds to seconds, holds locks the whole time.
• Long‑running (Saga‑style): can take minutes, hours, or days (e.g. a hotel booking that waits for hotel confirmation), and does not hold locks the whole time.

Let’s look at the actual building blocks that make a distributed transaction system work.

4.1 The Standard Components

Fig 4.1 — A typical distributed‑transaction architecture with a coordinator, participants, and an event backbone.

4.2 Why a Separate Coordinator?

You could try to make participants talk to each other directly without any coordinator (this is called choreography), but as the number of services grows, this becomes a tangled web that’s hard to reason about. A coordinator (orchestration) centralizes the decision‑making, making the flow easier to visualize, debug, and monitor — at the cost of a single component that must itself be made highly available.

Let’s go under the hood of the two most important mechanisms: Two‑Phase Commit and Sagas. We’ll cover more protocols in Section 7, but here we build the intuition first.

5.1 Two‑Phase Commit (2PC) — Step by Step

2PC works exactly like its name says: two phases.

1. Phase 1 — Prepare (Voting): the coordinator asks every participant, “Can you commit your part?” Each participant does all the work needed, writes it to its own durable log, but does not make it permanently visible yet. It then replies “Yes, I’m ready” (Vote‑Commit) or “No, I can’t” (Vote‑Abort).
2. Phase 2 — Commit/Abort (Decision): if all participants voted yes, the coordinator tells everyone to commit for real. If even one voted no, the coordinator tells everyone to abort/rollback.

Figs 5.1 & 5.2 — A successful Two‑Phase Commit where both participants vote yes, and the alternative abort path when any participant votes no.

5.2 The “Blocking Problem” in 2PC

2PC has a famous weakness: if the coordinator crashes right after Phase 1 (after collecting votes) but before sending the Phase 2 decision, every participant is stuck. They’ve already said “I’m ready” and locked their resources, but they don’t know whether to commit or abort — they must simply wait (block) until the coordinator recovers. This is why 2PC is called a blocking protocol.

5.3 Sagas — Step by Step

A Saga breaks a long transaction into a sequence of small, independent local transactions. Each local transaction commits immediately (no waiting, no locks held across services). If a later step fails, the Saga runs compensating transactions to undo the already‑completed steps, in reverse order.

Fig 5.3 — A Saga that fails midway and compensates the earlier successful step.

Every distributed transaction, regardless of protocol, moves through a predictable lifecycle. Understanding these states is critical for debugging and for interviews.

Fig 6.1 — The general lifecycle states of a distributed transaction.

6.1 Lifecycle Explained

1. Initiated: a client request triggers the start of a transaction, and a unique transaction ID is generated. This ID is attached to every message so all services can correlate the work (essential for tracing, covered in Section 12).
2. In Progress: the coordinator sends commands to participants one by one (Saga) or in parallel (2PC prepare phase).
3. Preparing / Voting (2PC only): participants tentatively do the work and report readiness.
4. Committing or Aborting: the final decision is made and broadcast.
5. Compensating (Saga only): if something failed partway, previously completed steps are reversed via compensating actions.
6. Terminal State: Committed, Aborted, or Compensated — the transaction record is archived, and the transaction log entry can eventually be cleaned up.

Now let’s go deeper into the four most important protocols you’ll encounter in real systems and interviews.

7.1 Two‑Phase Commit (2PC) — Recap and Java Example

2PC is strongly consistent but blocking and synchronous. It works best for a small number of participants that are all reachable and fast (e.g. within one data center, using XA‑compliant resources like JDBC + JMS).

Java Example (using JTA‑style pseudocode with an XA‑like coordinator):

// A simplified illustration of how a Java Transaction API (JTA) style
// coordinator drives a Two-Phase Commit across two XA resources.

public class TwoPhaseCommitCoordinator {

    private final List<XAResourceParticipant> participants;

    public TwoPhaseCommitCoordinator(List<XAResourceParticipant> participants) {
        this.participants = participants;
    }

    public boolean executeTransaction() {
        List<XAResourceParticipant> prepared = new ArrayList<>();

        // PHASE 1: PREPARE
        for (XAResourceParticipant p : participants) {
            boolean voteCommit = p.prepare();     // does the work, writes to local log
            if (!voteCommit) {
                // Someone voted NO -> abort everyone that already prepared
                rollbackAll(prepared);
                return false;
            }
            prepared.add(p);
        }

        // PHASE 2: COMMIT (only reached if everyone voted YES)
        for (XAResourceParticipant p : participants) {
            p.commit();
        }
        return true;
    }

    private void rollbackAll(List<XAResourceParticipant> prepared) {
        for (XAResourceParticipant p : prepared) {
            p.rollback();
        }
    }
}

interface XAResourceParticipant {
    boolean prepare();   // returns true if this participant can safely commit
    void commit();
    void rollback();
}

Explanation: the coordinator first asks every participant to prepare(). Only if all return true does it call commit() on everyone; otherwise it calls rollback() on the ones that already prepared. This mirrors exactly what real JTA transaction managers (like Atomikos or Narayana) do internally.

7.2 Three‑Phase Commit (3PC)

3PC adds an extra step (“pre‑commit”) between voting and committing, along with timeouts, specifically to reduce the blocking problem of 2PC. If the coordinator crashes, participants that reached “pre‑commit” can safely assume the transaction was heading toward commit and can proceed without waiting forever.

7.3 Saga Pattern — Orchestration vs. Choreography

There are two ways to implement a Saga:

Fig 7.1 — Choreography: services react to each other’s events with no central controller.

Java Example (Saga Orchestrator, simplified):

public class OrderSagaOrchestrator {

    private final InventoryClient inventoryClient;
    private final PaymentClient paymentClient;
    private final ShippingClient shippingClient;

    public SagaResult placeOrder(OrderRequest request) {
        String sagaId = UUID.randomUUID().toString();
        List<Runnable> compensations = new ArrayList<>();

        try {
            inventoryClient.reserveItem(sagaId, request.getItemId(), request.getQty());
            compensations.add(() -> inventoryClient.releaseItem(sagaId, request.getItemId()));

            paymentClient.charge(sagaId, request.getCustomerId(), request.getAmount());
            compensations.add(() -> paymentClient.refund(sagaId, request.getCustomerId()));

            shippingClient.scheduleDelivery(sagaId, request.getAddress());
            compensations.add(() -> shippingClient.cancelDelivery(sagaId));

            return SagaResult.success(sagaId);

        } catch (SagaStepException ex) {
            // Run compensations in reverse order
            Collections.reverse(compensations);
            for (Runnable compensate : compensations) {
                try {
                    compensate.run();
                } catch (Exception compEx) {
                    // Log and alert - compensation failures need human/automated retry
                    Alerting.raise("Compensation failed for saga " + sagaId, compEx);
                }
            }
            return SagaResult.failed(sagaId, ex.getMessage());
        }
    }
}

Explanation: every successful step pushes a matching compensation onto a stack‑like list. If a later step throws, we run compensations in reverse order — exactly like undoing a stack of actions. Note that compensation failures are logged for alerting, because compensations themselves can fail and need special handling (often a retry queue or manual intervention).

7.4 TCC — Try, Confirm, Cancel

TCC is a more structured variant of Saga, popular in the payments and e‑commerce world (used heavily by Alibaba’s Seata framework, for example). Every operation is split into three explicit phases:

• Try: reserve resources without finalizing (e.g. “hold” ₹500, don’t deduct it yet).
• Confirm: if all Try steps succeeded, actually finalize the reservation (deduct the held ₹500).
• Cancel: if any Try step failed, release the reservation (unhold the ₹500).

Fig 7.2 — TCC pattern: reserve first, finalize (or cancel) second.

TCC gives stronger guarantees than a plain Saga (because resources are explicitly “held,” preventing others from using them mid‑transaction) but requires more implementation effort — every service must implement all three operations.

7.5 Comparing the Protocols

Distributed transactions solve real, painful problems — but they are not free. Being honest about both sides will save you from a lot of pain later.

8.1 Advantages of Using Distributed Transactions

• Keeps data correct and trustworthy across independently owned systems.
• Prevents “half‑completed” business operations (e.g. charged but no order).
• Enables safe scaling — each service/database can grow independently while still cooperating correctly.
• Provides clear recovery semantics after crashes (via logs and compensations).

8.2 Disadvantages

• Complexity: significantly harder to design, test, and debug than local transactions.
• Latency: coordinating multiple network calls is inherently slower than one local commit.
• Availability trade‑off: strong protocols like 2PC reduce availability during coordinator failure.
• Operational burden: requires dedicated monitoring, dead‑letter queues, and compensation logic.
• Partial visibility: with Sagas, other parts of the system might briefly see “in‑progress” or inconsistent state (eventual consistency window).

8.3 Trade‑off Table

Every additional participant adds another network hop and another opportunity for something to go wrong. That’s why performance work here starts with reducing coordination itself.

9.1 Why Distributed Transactions Are Slower

Every extra network round trip adds latency. If a 2PC transaction involves 4 participants, and each round trip takes ~20 ms, the Prepare phase alone can take 20–40 ms (parallel calls), plus the Commit phase another 20–40 ms — before we even count database work. Under load, holding locks during this window can drastically reduce throughput.

9.2 Techniques to Improve Performance

• Parallelize Prepare calls: send prepare requests to all participants simultaneously instead of one by one.
• Reduce participant count: design service boundaries so a single business transaction touches as few services as possible.
• Use async messaging (event‑driven Sagas): avoid holding connections/locks open while waiting for slow steps.
• Batching: group many small transactions into fewer, larger ones where correctness allows.
• Local‑first design (Outbox Pattern): write business data and the “event to send” in the same local database transaction, then publish asynchronously — avoiding a distributed transaction entirely for many cases.

Fig 9.1 — Transactional Outbox Pattern avoids a distributed transaction between a DB and a message broker.

9.3 Scalability Considerations

As traffic grows, coordinators can become bottlenecks. Solutions include sharding the coordinator by transaction ID, using horizontally scalable workflow engines (like Temporal, which persists state and can run many worker processes), and preferring choreography for very high‑throughput flows where a central orchestrator would become a hotspot.

A distributed transaction system is only as available as its coordinator plus its logs. Everything in this section is about making sure a single failure never means “the whole thing is stuck.”

10.1 Making the Coordinator Highly Available

Since the coordinator is critical, it must never be a single point of failure. Common techniques:

• Persistent transaction log: every decision is written to durable storage (disk, or a replicated log like Kafka) before being sent to participants, so a crashed coordinator can recover its exact state on restart.
• Leader election: multiple coordinator instances run, but only one is “active” at a time, elected using a consensus algorithm like Raft (see Section 17).
• Idempotent participant operations: so that if the coordinator retries a command after recovering, it doesn’t cause duplicate side effects.

10.2 Timeouts and Retries

If a participant doesn’t respond within a set time, the coordinator must have a policy: retry, escalate to a human, or mark the transaction as “failed, needs compensation.” Exponential backoff (waiting longer between each retry) prevents overwhelming a struggling service.

10.3 Circuit Breakers

When a participant service is consistently failing, a circuit breaker stops sending it new requests for a cooldown period, failing fast instead of piling up timeouts. This protects both the struggling service (giving it room to recover) and the overall system’s responsiveness.

Fig 10.1 — Circuit breaker states used to protect participants from cascading failure.

10.4 Disaster Recovery

Transaction logs should be replicated across availability zones (or regions for critical financial systems). Regular backups plus tested restore procedures (measured with RPO — Recovery Point Objective, and RTO — Recovery Time Objective) ensure that even a full data center outage doesn’t permanently corrupt transaction history.

Every extra network hop is another surface an attacker can probe. Distributed‑transaction security is really about protecting the coordinator‑participant conversation from tampering, replay, and impersonation.

11.1 Key Security Concerns

• Authentication between services: every participant must verify that commands genuinely come from the real coordinator (e.g. using mutual TLS or signed service tokens like JWTs), preventing a malicious actor from injecting fake “commit” commands.
• Authorization: even a legitimate coordinator should only be allowed to trigger operations it’s permitted to (principle of least privilege) — a shipping‑related coordinator shouldn’t be able to directly modify payment records.
• Data‑in‑transit encryption: all coordinator‑participant communication should use TLS to prevent eavesdropping or tampering with transaction data (like amounts or account numbers).
• Replay attack protection: idempotency keys and nonces prevent an attacker from re‑sending an old, captured “commit” or “charge” message to cause duplicate effects.
• Audit logging: every state transition (prepared, committed, compensated) should be logged immutably for compliance (important in finance and healthcare under regulations like PCI‑DSS, SOX, HIPAA).

11.2 Securing Compensations

Compensating actions (like refunds) are sensitive and must themselves be authenticated and rate‑limited — an attacker triggering fake compensations repeatedly could be used to drain a company’s funds or manipulate inventory counts.

You cannot fix what you cannot see. In a world of many services and many messages, observability is the difference between a two‑minute incident and a two‑hour outage.

12.1 Distributed Tracing

Because a single business transaction spans many services, you need a way to see the whole journey. This is done using a trace ID (also called a correlation ID), generated once at the start and passed through every service call and every message.

Fig 12.1 — A trace timeline showing how long each service took within one transaction.

12.2 Key Metrics to Track

12.3 Alerting & Dashboards

Set alerts on rising compensation rates, growing DLQ size, or transactions stuck longer than an expected SLA (e.g. “no order should stay ‘in‑progress’ for more than 5 minutes”). Structured logging (JSON logs with the trace ID as a field) makes it possible to query “show me every log line for trace‑id 8f21ac” instantly in tools like Elasticsearch/Kibana or Splunk.

Every major cloud offers building blocks for this problem — you rarely need to build a coordinator from scratch anymore.

13.1 Cloud‑Native Building Blocks

13.2 Deployment Considerations

• Multi‑region deployments: coordinators and their logs should be replicated across regions for critical systems (e.g. global payment platforms), but cross‑region latency must be factored into timeout settings.
• Blue‑green / canary releases: when deploying a new version of a participant service, ensure it stays backward‑compatible with in‑flight transactions started by the old version.
• Schema evolution: event payloads (used in Sagas) should be versioned so old and new consumers can coexist during rollout.
• Cost optimization: frequent short‑lived distributed transactions can be expensive at scale (network egress, message broker throughput charges) — batching and outbox patterns help reduce cost.

The database is the ground truth. Your caching and load‑balancing decisions must respect its transactional boundary — not fight it.

14.1 Database Choices for Distributed Transactions

• XA‑compliant databases (Oracle, PostgreSQL, MySQL with XA support): support classic 2PC directly.
• NewSQL / Distributed SQL databases (Google Spanner, CockroachDB, YugabyteDB, TiDB): provide ACID transactions across nodes internally, using consensus protocols under the hood, so application developers get strong consistency without manually implementing 2PC.
• NoSQL databases (MongoDB, DynamoDB, Cassandra): traditionally favored availability and partition tolerance over strict cross‑document/cross‑partition transactions, though many now offer limited multi‑document ACID transactions (e.g. MongoDB since version 4.0).

14.2 Caching Considerations

Caches (like Redis) sit outside the transactional boundary, so a rollback of the underlying database won’t automatically undo a cache update. Strategies to handle this:

• Cache‑aside with short TTLs: accept brief staleness, but expire cache entries quickly.
• Invalidate‑on‑commit: only update/invalidate cache entries after the transaction reaches a terminal “Committed” state, never during “in‑progress.”
• Write‑through with compensation: if a compensating transaction runs, explicitly issue a matching cache invalidation as part of the compensation logic.

14.3 Load Balancing the Coordinator

Coordinator instances behind a load balancer must share transaction state (via a shared, replicated log or database) — a request to “check status of transaction X” must return the same answer no matter which coordinator instance handles it. This usually means the load balancer is stateless, and all coordinator instances read/write to a common, consistent transaction log store.

Fig 14.1 — Multiple coordinator instances sharing one consistent transaction log for high availability.

The API you expose to callers largely decides how safe your service is inside a distributed transaction. A few small choices — idempotency keys, explicit states, matching compensations — save enormous pain later.

15.1 Designing APIs for Distributed Transactions

• Always accept an idempotency key in write APIs (e.g. POST /payments with header Idempotency-Key: abc-123).
• Return explicit status, not just success/failure: APIs should support states like PENDING, RESERVED, CONFIRMED, CANCELLED so orchestrators can poll or react correctly.
• Design compensating endpoints alongside the primary action: if you build POST /reserve, also build POST /release from day one.
• Version your events: include a schema version field in event payloads so consumers can handle changes gracefully.

Java Example — A Spring‑style REST controller with idempotency support:

@RestController
@RequestMapping("/payments")
public class PaymentController {

    private final IdempotencyStore idempotencyStore;
    private final PaymentService paymentService;

    @PostMapping
    public ResponseEntity<PaymentResponse> charge(
            @RequestHeader("Idempotency-Key") String idempotencyKey,
            @RequestBody PaymentRequest request) {

        Optional<PaymentResponse> existing = idempotencyStore.get(idempotencyKey);
        if (existing.isPresent()) {
            // Same request seen before -> return the SAME result, don't charge again
            return ResponseEntity.ok(existing.get());
        }

        PaymentResponse response = paymentService.charge(request);
        idempotencyStore.save(idempotencyKey, response);
        return ResponseEntity.ok(response);
    }
}

Explanation: before doing any real work, the controller checks whether this exact Idempotency-Key has already been processed. If yes, it returns the cached result instead of charging the customer again — this single pattern prevents an enormous class of distributed‑transaction bugs caused by network retries.

15.2 Microservices Boundaries

Good microservice design tries to minimize the need for distributed transactions in the first place, by drawing service boundaries around business capabilities that naturally change together (a concept from Domain‑Driven Design called a “Bounded Context”). When a single business action genuinely needs multiple services, that’s when Sagas or TCC come in.

A short catalogue of patterns you should reach for, and anti‑patterns you should learn to spot in code reviews and design sessions.

16.1 Recommended Patterns

16.2 Common Anti‑patterns to Avoid

Underneath every reliable distributed transaction system sits a handful of theoretical ideas. You don’t need to be an academic to use them, but knowing them makes system behaviour under stress much less mysterious.

17.1 The CAP Theorem

The CAP theorem, formulated by computer scientist Eric Brewer in 2000, states that a distributed data system can only guarantee two of these three properties at the same time, when a network partition happens:

• Consistency (C): every read receives the most recent write or an error.
• Availability (A): every request receives a (non‑error) response, even without the latest data.
• Partition Tolerance (P): the system keeps working even if network messages are lost or delayed between nodes.

Since network partitions are unavoidable in real distributed systems (P is mandatory), the real‑world choice is between CP systems (like Google Spanner, HBase, MongoDB in certain configurations) and AP systems (like Cassandra, DynamoDB in default mode, Amazon S3 historically). This directly shapes distributed transaction design: strongly consistent protocols like 2PC lean CP; Sagas embrace an AP mindset with eventual consistency.

Fig 17.1 — CAP theorem: partition tolerance is mandatory, so real systems choose between CP and AP.

17.2 Consensus Algorithms: Paxos & Raft

Coordinators, leader elections, and distributed logs all rely on consensus algorithms — protocols that let a group of machines agree on a single value even if some of them crash or messages are lost.

Raft (designed in 2014 specifically to be easier to understand than Paxos) works by electing a leader among a cluster of nodes. The leader receives all writes, replicates them to a majority of follower nodes, and only considers a write “committed” once a majority acknowledges it. If the leader crashes, followers hold a new election.

Fig 17.2 — Raft consensus: a write is committed once a majority of nodes acknowledge it.

17.3 Replication Strategies

17.4 Partitioning (Sharding)

Large distributed systems split data into shards (partitions), each holding a subset of data (e.g. users A–M on shard 1, N–Z on shard 2). Distributed transactions that span multiple shards face the same coordination challenges as transactions spanning multiple services — this is why cross‑shard transactions are often deliberately avoided or handled with the same 2PC/Saga techniques discussed above.

17.5 Failure Recovery

Robust distributed transaction systems must handle every type of failure:

• Coordinator crash before decision: on restart, the coordinator reads its durable log to find any in‑doubt transactions and re‑asks participants or re‑sends the last known decision.
• Participant crash mid‑prepare: on restart, the participant checks its own local log; if it had voted “yes” but never received a final decision, it must contact the coordinator to find out the outcome (this is the “in‑doubt” state).
• Message loss: handled via retries with idempotency, and timeouts that eventually trigger compensation.
• Split‑brain (two nodes both think they’re the leader): prevented by quorum‑based consensus — a leader is only valid if it can prove it has a majority of votes.

Fig 17.3 — Coordinator recovery flow after a crash, using the durable transaction log.

These are the habits that separate teams who ship a distributed‑transaction system once and forget it, from teams who spend every Friday night firefighting.

18.1 Best Practices

• ProtocolPrefer Sagas over 2PC for cross‑microservice workflows unless you have a small, tightly‑coupled set of participants that truly need strong consistency.
• IdempotencyMake every write operation idempotent from day one — don’t bolt it on later.
• CompensationsAlways design and test compensating actions as rigorously as the main flow (write automated tests that simulate failures at every step).
• OutboxUse a transactional outbox instead of dual‑writing to a database and a message broker separately.
• TracingPropagate a trace/correlation ID through every service call and log line.
• TimeoutsSet clear timeouts for every step, and define what happens on timeout (retry? compensate? alert a human?).
• ScopeKeep the number of participants in any single distributed transaction as small as possible.
• ObservabilityBuild dashboards and alerts for compensation rate, stuck transactions, and DLQ depth before going to production, not after an incident.

18.2 Common Mistakes

Everything you’ve seen so far already runs, at enormous scale, inside companies you use every day.

A quick refresher on the questions that come up most often, followed by a compact wrap‑up of everything you now know.

Frequently Asked Questions

Summary

A distributed transaction is how independent, networked systems cooperate to make sure a business operation either fully succeeds or fully fails — never getting stuck halfway. We started with the simple guarantee of ACID transactions on a single machine, saw why that guarantee breaks down once data is split across services, and explored the two major families of solutions: strongly consistent, blocking protocols like Two‑Phase Commit and Three‑Phase Commit, and flexible, resilient patterns like Sagas and TCC that favor availability and eventual consistency. We covered the real components (coordinators, participants, transaction logs, outboxes), the full lifecycle from initiation to a terminal state, and dove into advanced foundations like the CAP theorem, consensus algorithms (Paxos/Raft), replication, and failure recovery — the same ideas that power globally distributed databases like Google Spanner. Finally, we looked at how real companies like Amazon, Netflix, and Uber apply these ideas at massive scale in production.

Key Takeaways

“A distributed transaction doesn’t promise nothing will fail — it promises that failure won’t leave your data in a half‑done state.”

With this foundation, you’re now equipped to design, build, and operate distributed transactions the way real production systems do — choosing the right protocol for the right situation, and building in the resilience that large‑scale systems demand. Everything else in this space — workflow engines, service meshes, outbox pipelines, event stores — is a specialised expression of the same core idea: describe your desired outcome, coordinate carefully, log everything, and always have a way to undo what you’ve already done.