Comparing Distributed Transaction Strategies: Local Messages, RocketMQ, and Seata (AT & TCC)

Local Message Table

Using an order‑success event to deduct inventory, a record is written and a message is sent to achieve eventual consistency between two services.

Advantages: Simple logic, minimal development effort.

Disadvantages: Strongly coupled with business logic, consumes business system resources, limited applicability.

RocketMQ Transactional Messages

After an order is placed successfully, points are added using RocketMQ's transactional messaging to ensure eventual consistency.

Advantages: Middleware already implements transaction logic, no extra configuration needed.

Disadvantages: Real‑time guarantees are weak, business must eventually succeed, transaction‑message code is not open‑source.

Seata AT Mode

The AT mode improves the two‑phase commit protocol with low code intrusion (just import a JAR) and convenient operation. The transaction coordinator (TC) persists branch statuses; successful branches are marked, while unmarked branches are retried by TC’s timer, guaranteeing eventual consistency of all branches.

Limitation: only works with relational databases; it does not support transactions across services using MySQL and Redis/Elasticsearch.

Seata TCC Mode

To address scenarios where AT is unsuitable, Seata provides a TCC (Try‑Confirm‑Cancel) mode. The diagram below shows the official TCC workflow, followed by a concrete order‑processing example.

Try Phase

Red packet service: Deduct payment amount from the red packet and record the deduction.

Points service: No operation (the add‑points action is guaranteed to succeed later).

Order service: Change order status to "payment in progress" to prevent timeout cancellation.

Confirm Phase

Red packet service: No further action, money already deducted.

Points service: Add points.

Order service: Update order status to "paid".

Cancel Phase

Red packet service: Retrieve the original payment record and refund the amount to the red packet account.

Points service: No operation.

Order service: Set order status to "payment failed".

TCC Exception Handling

Empty Rollback : If the order service fails to call the points service due to network issues, the TC triggers a rollback, but the points service may execute cancel without a prior try, causing an empty rollback. Solution: Add a log table to record whether try was executed; skip cancel if try did not run.

Idempotency : The second‑phase methods may be invoked multiple times due to retries, leading to idempotency problems. Solution: Implement idempotent logic in the points service, e.g., using a state machine.

Hanging Prevention : Resources may be reserved in the try phase, but if TC notifies the points service to cancel before try completes, the transaction ends prematurely and points cannot be rolled back. Solution: Record both try and cancel attempts in a log table; if a try record exists, delay cancel execution until the next retry.

These are the common solutions for distributed transaction problems, aiming to help developers choose the appropriate strategy for their micro‑service architectures.