The Distributed Transaction ‘Silver Bullet’ Myth: Practical SAGA, TCC, and Outbox Implementation

Conclusion: No Silver Bullet, Only Trade‑offs

When a system moves to micro‑services, heterogeneous storage, message‑driven architecture, and cross‑team collaboration, transaction problems become a design trade‑off among consistency strength, real‑time requirements, throughput, development complexity, operational cost, and organizational coordination.

There is no single framework that solves everything; the answer is to ask four questions:

How strong does consistency need to be?

How long can inconsistency be tolerated and in what form?

After a failure, should the system roll back, compensate, replay, or rely on manual recovery?

How does the solution behave under high concurrency and how easy is it to operate?

The article then evaluates three mainstream patterns—SAGA, TCC, and Outbox—against these questions and presents a mixed‑architecture recommendation.

Why Two‑Phase Commit (2PC) Is Rarely Used in Internet‑Scale Systems

2PC guarantees atomic commit across multiple resource managers by locking resources in the Prepare phase and releasing them in the Commit phase. Its theoretical correctness is solid, but the engineering cost is prohibitive:

Locks are held for a long time, dramatically reducing throughput.

The coordinator becomes a single point of failure; network partitions and timeouts cause blocking and complex recovery.

Many modern resources (Kafka, Redis, third‑party services) do not support XA.

Cloud‑native environments add container restarts, elastic scaling, and multi‑AZ scheduling, making long‑held locks fragile.

Consequently, production systems prefer "recoverable consistency" rather than strict ACID across services.

Core Contradiction of Distributed Transactions: Focus on Failure, Not Success

Typical business flow:

用户下单
  → 订单服务创建订单
  → 库存服务扣减库存
  → 支付服务冻结或扣款
  → 营销服务锁定优惠券
  → 物流服务创建发货单

Each step can fail in many ways (business, technical, duplicate, out‑of‑order, partial success, etc.). The real design goal is to make every step:

Explicitly bounded in state.

Recoverable and retryable.

Idempotent.

Detectable when out of order.

Observable on the error path.

SAGA, TCC, and Outbox all address this problem from different angles.

Selection Table (Architect’s View)

Pattern | Transaction Nature                | Consistency Model | Typical Advantages                         | Typical Costs                                 | Best Fit
--------|----------------------------------|-------------------|--------------------------------------------|-----------------------------------------------|----------
SAGA    | Long transaction split into local + compensation | Eventual consistency | Natural business expression, good for long flows | Complex compensation, state management        | Order fulfillment, refunds, approvals, cross‑domain orchestration
TCC     | Resource reservation + confirm/cancel               | Eventual consistency with stronger isolation | Higher performance than long‑lock transactions, fits high‑value resources | Intrusive, complex interfaces                | Inventory, balance, coupon reservation
Outbox  | Write business data + event record in same local transaction | Reliable event consistency | Solves "db write succeeded but message lost" | Does not solve cross‑service atomic commit | Event‑driven, async decoupling, domain event publishing

Key take‑aways:

Outbox is never a replacement for SAGA or TCC; it complements them.

Most production systems combine the three patterns.

Engineering Baselines Required by All Patterns

Idempotency : request id + unique index, global transaction id (xid/sagaId/txId), event deduplication.

Empty Compensation / Empty Rollback : If the forward action never executed, compensation should succeed silently.

Suspended (Hang) Handling : Cancel must set a marker; Try must check the marker before proceeding.

Timeout & Retry : Define timeout thresholds, max retry count, back‑off strategy, dead‑letter handling, and manual intervention entry.

Observability : Emit traceId, xid/sagaId, business key, step, status, retryCount, costMs, etc., and monitor compensation success rate, failure rate, timeout rate, backlog, outbox pending count, dead‑letter queue size.

SAGA: Long‑Process Business with Compensation

Essence of SAGA

SAGA splits a long transaction into a series of local transactions. When a later step fails, compensation actions are executed to bring the system to an acceptable state. Compensation is business‑level rollback, not database rollback.

Example:

Forward: Order created, inventory deducted, payment frozen.

Failure at payment confirmation.

Compensation: Release inventory, close order, unfreeze payment.

Two Main Forms

Orchestration : Central coordinator decides the next step and which compensations to run. Advantages: visualizable flow, unified governance, suitable for complex chains. Disadvantages: coordinator is a critical component, requires state‑machine maintenance.

Choreography : Services emit events and react autonomously. Advantages: service autonomy, stronger decoupling. Disadvantages: harder to trace, state divergence makes debugging difficult.

For most medium‑to‑large systems that need clear audit and compensation chains, orchestration is easier to maintain.

Real‑World Order Fulfillment SAGA

CreateOrder → ReserveInventory → FreezePayment → LockCoupon → CreateDelivery

If CreateDelivery fails, compensation runs in reverse order:

CancelDelivery → UnlockCoupon → ReleasePayment → ReleaseInventory → CloseOrder

SAGA State Machine Design

Do not rely on a single log table. Use explicit tables for saga instances and steps:

CREATE TABLE saga_instance (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  saga_id VARCHAR(64) NOT NULL,
  business_key VARCHAR(64) NOT NULL,
  saga_type VARCHAR(64) NOT NULL,
  status VARCHAR(32) NOT NULL,
  current_step VARCHAR(64),
  payload JSON NOT NULL,
  retry_count INT NOT NULL DEFAULT 0,
  next_retry_time DATETIME,
  created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  UNIQUE KEY uk_saga_id (saga_id),
  KEY idx_status_retry (status, next_retry_time)
);

CREATE TABLE saga_step (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  saga_id VARCHAR(64) NOT NULL,
  step_name VARCHAR(64) NOT NULL,
  step_order INT NOT NULL,
  action_type VARCHAR(16) NOT NULL,
  status VARCHAR(32) NOT NULL,
  request_json JSON,
  response_json JSON,
  error_code VARCHAR(64),
  error_message VARCHAR(512),
  executed_at DATETIME,
  UNIQUE KEY uk_saga_step_action (saga_id, step_name, action_type)
);

Key points: saga_instance controls global state and retry. saga_step records which steps have run and which compensations are done. action_type distinguishes FORWARD vs COMPENSATE for idempotency.

Production‑Grade SAGA Orchestrator (Spring Boot 3 style)

public enum SagaStatus { INIT, RUNNING, COMPLETED, COMPENSATING, COMPENSATED, FAILED }

public record SagaCommand(String sagaId, Long orderId, Long userId, Long skuId, Integer quantity, BigDecimal amount, String traceId) {}

public interface SagaStepHandler {
    String stepName();
    StepResult execute(SagaCommand command);
    StepResult compensate(SagaCommand command);
}

public record StepResult(boolean success, boolean retryable, String code, String message) {
    public static StepResult ok() { return new StepResult(true, false, "OK", "success"); }
    public static StepResult fail(String code, String message, boolean retryable) { return new StepResult(false, retryable, code, message); }
}

@Service
public class OrderSagaOrchestrator {
    private final SagaInstanceRepository sagaInstanceRepository;
    private final SagaStepRepository sagaStepRepository;
    private final List<SagaStepHandler> stepHandlers;
    private final PlatformTransactionManager txManager;

    public OrderSagaOrchestrator(SagaInstanceRepository sagaInstanceRepository,
                                SagaStepRepository sagaStepRepository,
                                List<SagaStepHandler> stepHandlers,
                                PlatformTransactionManager txManager) {
        this.sagaInstanceRepository = sagaInstanceRepository;
        this.sagaStepRepository = sagaStepRepository;
        this.stepHandlers = stepHandlers;
        this.txManager = txManager;
    }

    public void start(SagaCommand command) {
        new TransactionTemplate(txManager).executeWithoutResult(status -> {
            sagaInstanceRepository.create(command.sagaId(), command.orderId(), "ORDER_FULFILL");
        });
        run(command);
    }

    public void run(SagaCommand command) {
        sagaInstanceRepository.markRunning(command.sagaId());
        List<SagaStepHandler> executed = new ArrayList<>();
        for (SagaStepHandler handler : stepHandlers) {
            if (sagaStepRepository.isForwardDone(command.sagaId(), handler.stepName())) {
                executed.add(handler);
                continue;
            }
            StepResult result = handler.execute(command);
            sagaStepRepository.recordForward(command.sagaId(), handler.stepName(), result);
            if (!result.success()) {
                sagaInstanceRepository.markCompensating(command.sagaId(), handler.stepName());
                compensate(command, executed);
                return;
            }
            executed.add(handler);
        }
        sagaInstanceRepository.markCompleted(command.sagaId());
    }

    private void compensate(SagaCommand command, List<SagaStepHandler> executed) {
        ListIterator<SagaStepHandler> iterator = executed.listIterator(executed.size());
        while (iterator.hasPrevious()) {
            SagaStepHandler handler = iterator.previous();
            if (sagaStepRepository.isCompensationDone(command.sagaId(), handler.stepName())) {
                continue;
            }
            StepResult result = handler.compensate(command);
            sagaStepRepository.recordCompensation(command.sagaId(), handler.stepName(), result);
            if (!result.success()) {
                sagaInstanceRepository.markFailed(command.sagaId(), handler.stepName(), result.message());
                return;
            }
        }
        sagaInstanceRepository.markCompensated(command.sagaId());
    }
}

Best fit: long‑process workflows such as order fulfillment, refunds, approvals, and cross‑domain orchestration. Not suitable for high‑contention resources like inventory or balance where immediate consistency is required.

TCC: Try‑Confirm‑Cancel for High‑Value Resources

Essence of TCC

TCC splits a business action into three phases:

Try : Check resource availability and reserve it.

Confirm : Commit the reservation.

Cancel : Release the reservation.

The value lies in turning "resource available" into an explicit business state, e.g., inventory is frozen rather than directly deducted.

Typical Use Cases

Inventory freeze

Account balance freeze

Credit‑limit reservation

Coupon, seat, or quota reservation

Common Pitfalls and Solutions

Empty Rollback : Cancel arrives but Try never succeeded. Solution – insert a cancel marker when no reservation exists; subsequent Try sees the marker and aborts.

Hang (Suspended) : Cancel executed, then a delayed Try succeeds. Solution – Try must check for a cancel marker first.

Idempotent Confirm/Cancel : Use a unique tx_id primary key and allow only valid state transitions.

Inventory Freeze Table (Illustrative)

CREATE TABLE inventory_freeze (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  tx_id VARCHAR(64) NOT NULL,
  order_id BIGINT NOT NULL,
  sku_id BIGINT NOT NULL,
  quantity INT NOT NULL,
  status VARCHAR(16) NOT NULL,
  expire_at DATETIME NOT NULL,
  created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  UNIQUE KEY uk_tx_id (tx_id),
  KEY idx_expire_status (expire_at, status)
);

Production‑Grade Inventory TCC Service

public interface InventoryTccService {
    void tryReserve(String txId, Long orderId, Long skuId, int quantity);
    void confirm(String txId);
    void cancel(String txId);
}

@Service
public class InventoryTccServiceImpl implements InventoryTccService {
    private final InventoryRepository inventoryRepository;
    private final InventoryFreezeRepository freezeRepository;
    private final PlatformTransactionManager txManager;

    @Override
    public void tryReserve(String txId, Long orderId, Long skuId, int quantity) {
        new TransactionTemplate(txManager).executeWithoutResult(status -> {
            FreezeRecord existing = freezeRepository.findByTxId(txId);
            if (existing != null) {
                if ("TRY".equals(existing.status()) || "CONFIRMED".equals(existing.status())) {
                    return; // already tried or confirmed
                }
                throw new IllegalStateException("transaction already canceled");
            }
            if (freezeRepository.existsCanceledMarker(txId)) {
                throw new IllegalStateException("transaction canceled before try");
            }
            int updated = inventoryRepository.freezeAvailableStock(skuId, quantity);
            if (updated != 1) {
                throw new IllegalStateException("insufficient stock");
            }
            freezeRepository.insert(new FreezeRecord(txId, orderId, skuId, quantity, "TRY", LocalDateTime.now().plusSeconds(30)));
        });
    }

    @Override
    public void confirm(String txId) {
        new TransactionTemplate(txManager).executeWithoutResult(status -> {
            FreezeRecord record = freezeRepository.findByTxId(txId);
            if (record == null || "CONFIRMED".equals(record.status()) || "CANCELED".equals(record.status())) {
                return;
            }
            inventoryRepository.commitFrozenStock(record.skuId(), record.quantity());
            freezeRepository.markConfirmed(txId);
        });
    }

    @Override
    public void cancel(String txId) {
        new TransactionTemplate(txManager).executeWithoutResult(status -> {
            FreezeRecord record = freezeRepository.findByTxId(txId);
            if (record == null) {
                freezeRepository.insertCanceledMarker(txId);
                return;
            }
            if ("CANCELED".equals(record.status()) || "CONFIRMED".equals(record.status())) {
                return;
            }
            inventoryRepository.releaseFrozenStock(record.skuId(), record.quantity());
            freezeRepository.markCanceled(txId);
        });
    }
}

High‑concurrency SQL for the Try phase (optimistic lock):

UPDATE inventory
SET available_stock = available_stock - #{quantity},
    frozen_stock    = frozen_stock + #{quantity},
    version        = version + 1
WHERE sku_id = #{skuId}
  AND available_stock >= #{quantity}
  AND version = #{version};

Advantages: no long‑held row locks, fast failure, works with retry. Drawbacks: hot‑SKU contention, possible lock storms; often combined with Redis pre‑deduction, sharding, or regional stock pools.

Outbox: Reliable Event Publishing from Local Transactions

Problem It Solves

Typical buggy code:

orderRepository.save(order);
kafkaTemplate.send("order-created", event);

If the DB commit succeeds but Kafka send fails, downstream services never see the order, leading to "ghost" orders.

Outbox Mechanism

Within a single local transaction, write business data and an event record to an outbox_event table. A separate relay process reads pending rows and publishes them to the message broker.

BEGIN;
  UPDATE order SET ...;
  INSERT INTO outbox_event (event_id, aggregate_type, aggregate_id, event_type, payload, headers, partition_key, status, retry_count, created_at)
    VALUES (...);
COMMIT;

Later, a relay job publishes the event and marks the row as PUBLISHED or updates retry_count on failure.

Outbox Table Design (Key Fields)

CREATE TABLE outbox_event (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  event_id VARCHAR(64) NOT NULL,
  aggregate_type VARCHAR(64) NOT NULL,
  aggregate_id VARCHAR(64) NOT NULL,
  event_type VARCHAR(64) NOT NULL,
  payload JSON NOT NULL,
  headers JSON NULL,
  partition_key VARCHAR(64) NOT NULL,
  status VARCHAR(16) NOT NULL,
  retry_count INT NOT NULL DEFAULT 0,
  next_retry_time DATETIME NULL,
  error_message VARCHAR(512) NULL,
  created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  published_at DATETIME NULL,
  UNIQUE KEY uk_event_id (event_id),
  KEY idx_status_retry (status, next_retry_time, created_at)
);

Important columns: event_id – global unique for idempotent consumption. partition_key – ensures ordering for the same business entity. retry_count and next_retry_time – drive exponential back‑off. headers – carry traceId, tenant, version, etc.

Production‑Grade Outbox Writer (Spring style)

@Service
public class OrderCommandService {
    private final OrderRepository orderRepository;
    private final OutboxRepository outboxRepository;

    @Transactional
    public Long createOrder(CreateOrderRequest request) {
        Order order = Order.create(request.userId(), request.skuId(), request.quantity(), request.amount());
        orderRepository.save(order);
        OrderCreatedEvent event = new OrderCreatedEvent(UUID.randomUUID().toString(), order.getId(), order.getUserId(), order.getSkuId(), order.getQuantity(), order.getAmount());
        outboxRepository.save(OutboxEventRecord.builder()
            .eventId(event.eventId())
            .aggregateType("ORDER")
            .aggregateId(String.valueOf(order.getId()))
            .eventType("OrderCreated")
            .partitionKey(String.valueOf(order.getId()))
            .payload(Jsons.toJson(event))
            .headers(Jsons.toJson(Map.of("traceId", TraceIdHolder.get())))
            .status("NEW")
            .build());
        return order.getId();
    }
}

Relay Job (Lock‑Batch, FOR UPDATE SKIP LOCKED)

@Service
public class OutboxRelayJob {
    private final OutboxRepository outboxRepository;
    private final KafkaTemplate<String, String> kafkaTemplate;
    private final PlatformTransactionManager txManager;

    @Scheduled(fixedDelayString = "${outbox.relay.fixed-delay:200}")
    public void relay() {
        List<OutboxEventRecord> batch = outboxRepository.lockBatchForPublish(100);
        for (OutboxEventRecord record : batch) {
            try {
                kafkaTemplate.send(topicOf(record.eventType()), record.partitionKey(), record.payload()).get(3, TimeUnit.SECONDS);
                new TransactionTemplate(txManager).executeWithoutResult(s -> outboxRepository.markPublished(record.id()));
            } catch (Exception ex) {
                new TransactionTemplate(txManager).executeWithoutResult(s -> outboxRepository.markRetry(record.id(), ex.getMessage()));
            }
        }
    }
}

-- SQL used by lockBatchForPublish --
SELECT * FROM outbox_event
WHERE status IN ('NEW','RETRY')
  AND (next_retry_time IS NULL OR next_retry_time <= NOW())
ORDER BY created_at
LIMIT 100
FOR UPDATE SKIP LOCKED;

Benefits: multiple relay instances can run concurrently without duplicate sends.

CDC‑Based Outbox (Debezium)

Instead of a custom relay, Debezium reads the outbox_event binlog and pushes rows to Kafka. Configuration example (MySQL connector) is provided in the source.

Consumer Idempotency

Consumers must deduplicate using event_id. Example:

@Service
public class InventoryEventConsumer {
    private final ConsumedEventRepository consumedEventRepository;
    private final InventoryService inventoryService;

    @KafkaListener(topics = "OrderCreated", groupId = "inventory-service")
    public void onOrderCreated(String message) {
        OrderCreatedEvent event = Jsons.fromJson(message, OrderCreatedEvent.class);
        if (consumedEventRepository.exists(event.eventId())) {
            return; // already processed
        }
        inventoryService.deduct(event.orderId(), event.skuId(), event.quantity());
        consumedEventRepository.save(event.eventId(), "OrderCreated");
    }
}

Without this guard, duplicate consumption would corrupt inventory, points, or coupons.

Combining the Three Patterns for Real‑World Architecture

Typical production system rarely uses a single pattern. A layered combination is common:

用户下单
  → 订单服务本地落库
  → 核心资源使用 TCC（库存冻结、余额冻结）
  → 事务状态由 SAGA 协调（成功 Confirm，失败 Cancel/补偿）
  → 每一步状态变化通过 Outbox 发布领域事件（积分、营销、履约、通知、报表）

Benefits:

TCC guarantees strong isolation for high‑value resources.

SAGA handles long‑running, multi‑domain orchestration and manual recovery.

Outbox ensures reliable event propagation without losing consistency.

High‑Concurrency Engineering Upgrades

1. Slimming the Primary Transaction Path

Only keep actions that are required to decide whether a trade can occur (order write, inventory freeze, balance freeze). All non‑critical side effects (coupon consumption, delivery creation, notifications) are moved to asynchronous Outbox events.

2. Hot‑Resource Sharding

For hot SKUs or credit limits, apply sharding, segment tables, Redis pre‑deduction, or MQ throttling to avoid database bottlenecks.

3. Fast Failure

Set RPC timeouts tighter than overall SLA.

Trigger compensation as soon as a downstream failure is detected.

Avoid infinite synchronous retries; use back‑off and circuit‑breaker.

4. Asynchronous Recovery

Recovery, retry, and compensation are performed by background jobs, not by the user‑facing request thread.

5. Event‑Bus Governance

Topic partition count matches throughput.

Critical events have dedicated topics.

Consumer group concurrency matches partition count.

Configure dead‑letter queues and alerting.

6. Database Optimizations

Ensure indexes cover saga_instance, saga_step, inventory_freeze, outbox_event.

Partition or archive large tables.

Batch scans with pagination for recovery jobs.

Production Recovery & Governance Design

11.1 Transaction Recovery Scheduler

@Component
public class TransactionRecoveryScheduler {
    private final SagaRecoveryService sagaRecoveryService;
    private final TccTimeoutService tccTimeoutService;
    private final OutboxRepairService outboxRepairService;

    @Scheduled(fixedDelay = 5000)
    public void recoverSaga() {
        sagaRecoveryService.recoverTimedOutTransactions(200);
    }

    @Scheduled(fixedDelay = 3000)
    public void recoverTcc() {
        tccTimeoutService.cancelExpiredTryRecords(500);
    }

    @Scheduled(fixedDelay = 2000)
    public void repairOutbox() {
        outboxRepairService.republishFailedEvents(500);
    }
}

11.2 Manual Intervention Backend

Operations staff must be able to view the current step of a transaction, which steps succeeded, error messages, retry count, and trigger manual retry, forced compensation, or abort.

11.3 Audit Logging

Record who performed a manual action, why, the original transaction state, and the resulting state. This is essential for payment or financial domains.

11.4 Multi‑Region Considerations

Prefer keeping the primary transaction within the same region.

Use eventual consistency for cross‑region communication.

Avoid long‑running strong‑consistency transactions across data centers.

Full Production Case: E‑Commerce Order System

Business Background

Normal TPS 3,000, peak 20,000.

Domains: order, inventory, payment, coupon, points, fulfillment.

Inventory and balance must never be negative.

Points and notifications can tolerate seconds‑level delay.

Fulfillment may timeout and requires async recovery.

Recommended Architecture

Synchronous core path : order write, inventory TCC Try, payment TCC Try.

Success path : Confirm inventory, Confirm payment, mark order CONFIRMED.

Failure path : Cancel payment, Cancel inventory, mark order FAILED.

Asynchronous extensions (Outbox events) : OrderConfirmed, CouponConsumeRequested, PointAccumulateRequested, DeliveryCreateRequested.

Long‑process governance : If fulfillment fails or manual review is needed, a SAGA instance tracks the state and allows manual re‑drive.

Why Not All TCC?

Because fulfillment, notification, and points are not high‑value resources; forcing them into TCC would add invasive interfaces and massive maintenance overhead.

Why Not All SAGA?

Inventory and balance require strong isolation; pure compensation‑based SAGA cannot prevent oversell.

Why Outbox Is Mandatory

Without reliable event publishing, downstream systems (points, fulfillment, marketing) would see inconsistent state, leading to costly manual reconciliation.

Implementation on Spring Boot 3 + Kafka + MySQL/PostgreSQL + K8s

Application framework: Spring Boot 3.

RPC: OpenFeign / gRPC / Dubbo as team prefers.

Message bus: Kafka.

Relational DB: MySQL or PostgreSQL.

Cache & idempotency helper: Redis.

Service registry: Nacos or Consul.

Observability: Micrometer + Prometheus + Grafana + OpenTelemetry.

Orchestration: custom lightweight state machine or Seata / Conductor / Temporal depending on complexity.

K8s Deployment Tips

Separate API pods from recovery/relay pods.

Use database row locking, ShedLock, or K8s Lease to avoid duplicate scans.

Externalize all thresholds, retry counts, batch sizes, and feature switches via ConfigMaps/Secrets.

Support gray‑release: canary deploy new compensation logic, event schema version, or state‑machine changes.

Common Pitfalls & Anti‑Patterns

Treating compensation as true rollback – it cannot revert irreversible external effects.

Assuming a simple Redis SETNX provides full idempotency – real idempotency must be persisted in the business state machine.

Synchronous endless retries – leads to RT explosion; use layered retry (short sync, async background, dead‑letter).

Missing a unified transaction ID (xid/sagaId/eventId) – makes root‑cause analysis impossible.

No operational view – without dashboards, recovery jobs, and dead‑letter browsers, teams resort to manual DB fixes.

Practical Selection Checklist

Resource property : Is the resource high‑value and cannot be oversold? → Prefer TCC.

Process length : Does the workflow span multiple domains or require manual steps? → Prefer SAGA.

Event requirement : Must the successful transaction reliably notify downstream systems? → Include Outbox.

Organizational cost : Does the team have capacity to maintain complex state machines and intrusive interfaces? If not, start with the simplest pattern that satisfies the critical requirements.

Typical recommendation: implement Outbox first, add TCC for core resources, and introduce SAGA only for long‑running orchestrations.

Final Summary

SAGA – best for long‑process orchestration; focus on compensation design and state recovery.

TCC – best for high‑value, contention‑heavy resources; focus on resource modeling and handling empty rollback / hang.

Outbox – guarantees that local DB writes and event publishing stay consistent; focus on reliable relay, consumer idempotency, and event governance.

In production, avoid a "one‑size‑fits‑all" approach; combine patterns according to resource criticality, process length, and event needs.

Never ignore recovery, audit, manual intervention, and observability – they are the true measures of a mature distributed‑transaction system.