Distributed Transaction Solutions and Interview Guide

Table of Contents

Two‑Phase Commit (XA) Scheme

TCC Scheme

Local Message Table

Reliable Message Final Consistency Scheme

Max‑Effort Notification Scheme

How does your company handle distributed transactions?

Interview Questions

1. Do you understand distributed transactions?

2. How does your team solve distributed transaction problems?

Interviewer Psychology Analysis

When a candidate mentions experience with distributed systems, interviewers almost always ask about distributed transactions; lacking knowledge of the various solutions will make the interview difficult.

Distributed systems are now standard, and so are the distributed transaction challenges they bring. Even if you have not implemented them, you should at least know the main schemes and their typical pitfalls, such as network issues in TCC or consistency problems in XA.

Interview Question Analysis

There are five major approaches to implementing distributed transactions:

XA (two‑phase commit)

TCC (Try‑Confirm‑Cancel)

Local Message Table

Reliable Message Final Consistency

Max‑Effort Notification

1. Two‑Phase Commit (XA) Scheme

The XA scheme uses a transaction manager to coordinate multiple resource managers (databases). The manager asks each database to prepare; if all reply OK, the transaction is committed, otherwise it is rolled back.

This approach works for single‑application scenarios that span multiple databases but relies heavily on the database layer, resulting in low performance and poor suitability for high‑concurrency workloads. It can be implemented with Spring + JTA.

In micro‑service architectures, cross‑database access is discouraged; each service should only operate its own database and communicate via service APIs.

2. TCC Scheme

TCC stands for Try, Confirm, Cancel.

Try: validate resources and lock or reserve them.

Confirm: execute the actual business logic.

Cancel: if any service fails, execute compensating roll‑back logic for the already‑successful steps.

TCC is rarely used because writing compensating code is complex and error‑prone, but it is suitable for financial scenarios where strong consistency is mandatory.

3. Local Message Table

This pattern, inspired by eBay, uses a local message table to achieve eventual consistency.

Workflow:

System A writes business data and a message record in the same local transaction.

System A sends the message to a message queue.

System B consumes the message, writes a record to its own message table, and performs its business logic within a transaction; if the message was already processed, the transaction rolls back.

After successful processing, both systems update the status of their message records.

If B fails, A periodically scans its table for unsent messages and retries.

The approach guarantees eventual consistency but depends heavily on the database and does not scale well under high concurrency.

4. Reliable Message Final Consistency Scheme

This scheme eliminates the local message table and relies directly on the message queue’s transactional capabilities (e.g., RocketMQ transactional messages).

Steps:

System A sends a “prepared” message; if sending fails, the business operation is aborted.

If the prepared message succeeds, A executes its local transaction; on success it sends a commit message, on failure it sends a rollback message.

B receives the commit message and executes its local transaction.

The MQ periodically polls prepared messages and invokes a callback to check the outcome of the local transaction, ensuring that a successful local transaction is not lost due to a failed commit message.

If B’s transaction fails, the system retries automatically until success or performs manual compensation for critical financial operations.

5. Max‑Effort Notification Scheme

After System A’s local transaction, it sends a message to the MQ. A dedicated “max‑effort notification” service consumes the message, records it, and calls System B’s API.

If B succeeds, the process ends; if B fails, the service repeatedly retries N times before giving up.

6. How Does Your Company Handle Distributed Transactions?

Typical answer: for strict financial scenarios we use TCC to guarantee strong consistency; for ordinary order‑stock updates we adopt the reliable message eventual‑consistency approach based on RocketMQ.

Note: RocketMQ versions prior to 3.2.6 support the described workflow; later versions have changed the API.