Distributed Transactions Interview Questions

Master Distributed Transactions with interview-focused questions covering Two-Phase Commit (2PC), Three-Phase Commit (3PC), XA Transactions, Saga Pattern, Compensation Transactions, Eventual Consistency, Outbox Pattern, TCC, Microservices, and enterprise production best practices.

Introduction

Traditional database transactions work well when

One Application
One Database
One Transaction Manager

are involved.

However, modern enterprise applications are built using

Microservices
Multiple Databases
Cloud Services
Event-Driven Systems
Kafka
REST APIs

A single business operation often spans multiple services.

Example

Order Service

↓

Inventory Service

↓

Payment Service

↓

Shipping Service

↓

Notification Service

Maintaining consistency across these systems requires Distributed Transactions.

Distributed Transactions are one of the most frequently asked topics in Senior Java, Spring Boot, Microservices, and System Design interviews.

Distributed Transaction Architecture

flowchart LR

Client --> OrderService["Order Service"]

OrderService["Order Service"] --> Inventory

OrderService["Order Service"] --> Payment

OrderService["Order Service"] --> Shipping

Inventory --> DatabaseA["Database A"]

Payment --> DatabaseB["Database B"]

Shipping --> DatabaseC["Database C"]

1. What is a Distributed Transaction?

Answer

A Distributed Transaction is a transaction that spans

multiple services,

multiple databases,

or multiple systems,

while ensuring overall data consistency.

Unlike a local transaction,

multiple transaction managers may participate.

Distributed Transaction Workflow

Client

↓

Order Service

↓

Payment

↓

Inventory

↓

Shipping

↓

Success

2. Why are Distributed Transactions needed?

Modern systems contain

Multiple Databases
Microservices
Independent Deployments
Independent Scaling

One local transaction cannot cover all services.

3. What challenges exist in Distributed Transactions?

Challenges include

Network Failures
Partial Failures
Service Crashes
Timeouts
Data Consistency
Rollback Coordination

Challenges

Distributed System

↓

Network Failure

↓

Partial Update

↓

Recovery

4. What is a Local Transaction?

A Local Transaction

affects

only one database

using one transaction manager.

Example

Spring Boot

↓

MySQL

↓

Commit

5. Local vs Distributed Transaction

Local Transaction	Distributed Transaction
One Database	Multiple Databases
One Service	Multiple Services
Fast	Complex
Simple Rollback	Coordinated Rollback

6. What is XA Transaction?

XA (Extended Architecture)

is a standard

for coordinating

distributed transactions

across multiple resource managers.

XA is supported by

Oracle
MySQL
PostgreSQL
IBM MQ
JMS

XA Architecture

flowchart LR

TransactionManager["Transaction Manager"] --> DB1

TransactionManager["Transaction Manager"] --> DB2

TransactionManager["Transaction Manager"] --> MQ

7. What is Two-Phase Commit (2PC)?

Two-Phase Commit

is the most common protocol

used

for distributed transactions.

It consists of

Prepare Phase
Commit Phase

2PC Workflow

flowchart LR

Coordinator --> Prepare

Prepare --> Participant1["Participant 1"]

Prepare --> Participant2["Participant 2"]

Participant1["Participant 1"] --> Vote

Participant2["Participant 2"] --> Vote

Vote --> Commit

8. Explain Phase 1 (Prepare Phase)

Coordinator asks

every participant

Can you Commit?

Each participant replies

YES

or

NO

Prepare Phase

Coordinator

↓

Prepare?

↓

DB1

↓

YES

↓

DB2

↓

YES

9. Explain Phase 2 (Commit Phase)

every participant

returns

YES

Coordinator sends

COMMIT

Otherwise

ROLLBACK

Commit Phase

All YES

↓

Commit

----------------

One NO

↓

Rollback

10. What are disadvantages of 2PC?

Blocking
Coordinator Failure
Slow Performance
Network Dependency
Poor Scalability

11. What is Three-Phase Commit (3PC)?

3PC adds

one extra phase

to reduce blocking.

Phases

Can Commit
Pre Commit
Commit

3PC Workflow

Can Commit

↓

Pre Commit

↓

Commit

12. Is 3PC commonly used?

Not much.

Most modern systems

prefer

Saga Pattern

instead.

13. What is the Saga Pattern?

Saga breaks

one large transaction

into

multiple local transactions.

Each service commits independently.

If one fails,

Compensation Transactions

undo previous work.

Saga Architecture

flowchart LR

Order --> Inventory

Inventory --> Payment

Payment --> Shipping

Shipping --> Notification

14. What is a Compensation Transaction?

A Compensation Transaction

undoes

a previously completed transaction.

Example

Reserve Inventory

↓

Payment Failed

↓

Release Inventory

Compensation Workflow

Inventory Reserved

↓

Payment Failed

↓

Compensation

↓

Inventory Released

15. Choreography vs Orchestration Saga?

Choreography	Orchestration
Event Driven	Central Coordinator
Kafka Events	Saga Orchestrator
Decentralized	Centralized
Simpler Services	Easier Monitoring

16. What is Eventual Consistency?

Instead of

immediate consistency,

systems become

consistent

after

some time.

Used heavily in

microservices.

Eventual Consistency

Service A Updated

↓

Kafka Event

↓

Service B Updated

↓

Eventually Consistent

17. What is the Outbox Pattern?

The Outbox Pattern

stores

both

business data

and

event data

inside

the same local transaction.

Later,

a background process

publishes the event.

Outbox Pattern

flowchart LR

BusinessTable["Business Table"] --> OutboxTable["Outbox Table"]

OutboxTable["Outbox Table"] --> Kafka

18. Why is the Outbox Pattern used?

It prevents

Database Updated

BUT

Kafka Publish Failed

Both operations become reliable.

19. What is TCC (Try-Confirm-Cancel)?

TCC divides a transaction into three phases.

Try
Confirm
Cancel

Used for long-running distributed business processes.

TCC Workflow

Try

↓

Confirm

↓

Success

OR

Cancel

20. Banking Example

Money Transfer

Debit

↓

Credit

↓

Notification

Failure

↓

Compensation

↓

Refund

21. E-Commerce Example

Order

↓

Inventory

↓

Payment

↓

Shipping

Payment fails

↓

Release Inventory

22. Airline Booking Example

Reserve Seat

↓

Payment

↓

Ticket

Failure

↓

Release Seat

23. Healthcare Example

Patient

↓

Insurance

↓

Billing

↓

Appointment

Failure

↓

Cancel Appointment

24. Food Delivery Example

Create Order

↓

Restaurant

↓

Payment

↓

Delivery

Failure

↓

Refund

25. Stock Trading Example

Buy Stock

↓

Portfolio

↓

Wallet

↓

Notification

Failure

↓

Reverse Transaction

26. Production Example

Loan Approval

Loan Service

↓

Credit Service

↓

Fraud Service

↓

Notification

Fraud Failure

↓

Compensation

↓

Cancel Loan

27. Advantages

Supports Microservices
High Availability
Scalability
Independent Services
Business Consistency

28. Disadvantages

Complex Design
Eventual Consistency
Retry Logic
Compensation Logic
Monitoring Complexity

29. Performance Tips

Avoid XA unless absolutely required.
Prefer Saga for microservices.
Use Kafka for reliable messaging.
Keep local transactions short.
Make APIs idempotent.
Implement retries with exponential backoff.
Monitor failed compensations.

30. Best Practices

Prefer Saga over 2PC in microservices.
Use Outbox Pattern for reliable messaging.
Make every operation idempotent.
Implement compensation logic.
Design retry mechanisms.
Use correlation IDs for tracing.
Monitor distributed transactions.
Keep local transactions independent.
Avoid long-running XA transactions.
Test failure scenarios regularly.

Distributed Transaction Workflow

flowchart LR

Client --> OrderServiceLocalTransaction["Order Service --> Local Transaction --> Outbox --> Kafka --> Other Services --> CompensationIfNeeded["Compensation if Needed"]"]

Enterprise Best Practices

Use local ACID transactions within each service.
Prefer Saga Pattern over XA for cloud-native systems.
Use Kafka or RabbitMQ for asynchronous communication.
Implement idempotency to safely handle retries.
Store events using the Outbox Pattern.
Design compensation transactions carefully.
Monitor transaction failures with distributed tracing.
Use correlation IDs across services.
Handle partial failures gracefully.
Continuously test disaster recovery scenarios.

Quick Revision

Topic	Key Point
Distributed Transaction	Multiple Services
Local Transaction	Single Database
XA	Standard Distributed Transaction
2PC	Prepare + Commit
3PC	Can Commit + Pre Commit + Commit
Saga	Local Transactions + Compensation
Compensation	Undo Previous Action
Eventual Consistency	Consistency Over Time
Outbox Pattern	Reliable Event Publishing
TCC	Try, Confirm, Cancel

Interview Tips

Interviewers frequently ask

What is a Distributed Transaction?
Local vs Distributed Transaction.
Explain XA Transactions.
Explain Two-Phase Commit.
Explain Three-Phase Commit.
Saga Pattern vs 2PC.
Choreography vs Orchestration.
What is Eventual Consistency?
Explain Outbox Pattern.
How do you implement distributed transactions in Spring Boot microservices?

A strong interview explanation is:

"Distributed transactions coordinate a single business operation across multiple services or databases. Traditional systems use XA with Two-Phase Commit (2PC), where a coordinator manages prepare and commit phases. However, modern microservices usually prefer the Saga Pattern, which breaks the business process into local transactions and uses compensation transactions to recover from failures. Reliable event delivery is commonly achieved using the Outbox Pattern with Kafka, while idempotency and retries ensure resilient processing."

Summary

Distributed Transactions enable enterprise applications to maintain business consistency across multiple services and databases. While XA and Two-Phase Commit (2PC) provide strong consistency, modern cloud-native applications generally favor Saga Patterns, Compensation Transactions, Eventual Consistency, Outbox Pattern, and TCC to improve scalability and resilience.

Mastering Distributed Transactions, 2PC, 3PC, Saga, Outbox Pattern, Eventual Consistency, Kafka Integration, and Microservices Transaction Design is essential for Senior Java Developers, Backend Engineers, Solution Architects, and Distributed Systems Engineers building enterprise-scale applications.