Nail Distributed Transaction Consistency Questions in Interviews with This Full‑Score Answer

Interviewers often ask how to achieve distributed transaction consistency; simply reciting the two‑phase commit (2PC) process is unlikely to impress because few internet‑scale systems use 2PC.

Problem Essence

In an e‑commerce order, three independent systems—order service, inventory service, and promotion service—must either all succeed or all roll back, illustrating the core difficulty of ensuring atomicity across multiple servers and databases.

Two‑Phase Commit: Classic but Problematic

2PC involves a coordinator asking all participants to prepare (locking resources and writing logs) and then either committing if every participant replies “Yes” or rolling back otherwise. The article highlights three practical issues: deadlock risk during the prepare phase, performance bottlenecks caused by row locks that serialize requests, and potential data inconsistency when network failures cause some nodes to miss the commit command. Consequently, 2PC is suitable mainly for high‑consistency domains such as financial payments, but is generally infeasible for high‑concurrency internet services.

Message‑Queue (MQ) Solution: The Real‑World Choice

Most large internet companies adopt a reliable‑message‑delivery approach that sacrifices strong consistency for eventual consistency. In the order example, the order service publishes a "deduct coupon" event to a message queue; the coupon service consumes the event asynchronously. The MQ persists messages, so a broker crash does not lose data.

The three advantages are business decoupling, traffic shaping (the queue buffers spikes), and reliability (persistent storage). Interviewers, however, typically probe two critical points.

Core Interview Points: Double Confirmation and Message Compensation

1) Message loss: default auto‑acknowledge deletes a message as soon as a consumer receives it, which can cause loss if the consumer crashes mid‑process. The remedy is manual acknowledgment—only after the business logic succeeds does the consumer acknowledge the message.

2) High‑concurrency backlog: during traffic surges, the consumer may fall behind, leading to retries and possible dead‑letter queues. The recommended pattern is a two‑way confirmation mechanism: the order service first stores the outbound message in a local table marked "pending," sends it to the MQ, and then marks it "completed" only after receiving a confirmation from the coupon service. A scheduled task periodically scans for long‑pending messages and retries them, ensuring eventual consistency even if the MQ experiences failures.

Interview Answer Template

When faced with a distributed‑transaction question, structure the response as follows: first describe the practical MQ‑based reliable‑message solution and explain the double‑confirmation and local‑message‑table compensation details to demonstrate hands‑on experience; then optionally bring up 2PC and TCC, discuss their principles and drawbacks, and invite the interviewer to a deeper discussion.

One‑Sentence Takeaway

There is no silver bullet for distributed transactions; understanding business scenarios and choosing the appropriate consistency model is the architect’s core skill.