@Transactional Vs Distributed Transaction

This is one of the most common interview questions in Spring Boot and Microservices.

Many developers confuse @Transactional with Distributed Transactions, but they solve completely different problems.

---

@Transactional vs Distributed Transaction

Feature	@Transactional	Distributed Transaction
Scope	Single Database	Multiple Services/Databases
Works Within	One Spring Application	Multiple Microservices
Transaction Manager	Spring Transaction Manager	Saga, 2PC, TCC, etc.
Rollback	Automatic	Needs Compensation
ACID	Yes	Usually No (Eventual Consistency)
Performance	Fast	Slower
Complexity	Low	High

---

1. What is @Transactional?

@Transactional is used when all operations happen inside one application and generally one database transaction.

Example:

Order Service

Save Order
↓
Update Inventory Table
↓
Save Payment Details

Same Database

Code

@Transactional
public void placeOrder() {

    orderRepository.save(order);

    inventoryRepository.reduceStock(productId);

    paymentRepository.save(payment);
}

Everything executes inside one database transaction.

If any operation fails

Save Order ✔

Reduce Inventory ❌

Payment Not Executed

Entire transaction rolls back.

Order → Rollback

Inventory → Rollback

Payment → Rollback

Everything becomes exactly as before.

This is called Atomicity.

---

Interview Definition

@Transactional manages transactions within a single application and a single transactional resource, ensuring ACID properties.

---

2. What is Distributed Transaction?

Now imagine a Microservice architecture.

Customer

↓

Order Service

↓

Inventory Service

↓

Payment Service

↓

Shipping Service

Every service has

• Its own database
• Own transaction
• Own deployment

Now Order Service cannot control Payment Database.

Example

Order Service DB

Order Saved

Now it calls

Inventory Service

Inventory updates successfully.

Now it calls

Payment Service

Payment fails.

Question:

How will Order Service rollback Inventory Database?

It cannot.

Because

Inventory DB

!=

Order DB

Different databases.

Different services.

Different transactions.

This is called a Distributed Transaction problem.

---

Why @Transactional Cannot Solve This

Suppose

@Transactional
public void placeOrder(){

    orderRepository.save(order);

    inventoryClient.reduceStock();

    paymentClient.makePayment();
}

Looks fine.

But internally

Order DB Transaction

↓

REST Call

↓

Inventory Service

↓

Inventory DB Transaction

Inventory Service commits independently.

Now

Payment Service

↓

Throws Exception

Order transaction rolls back.

But Inventory has already committed.

Result

Order → Rolled Back

Inventory → Reduced

Payment → Failed

System becomes inconsistent.

---

Visual Flow

Order Service

@Transactional

↓

Save Order

↓

REST

↓

Inventory Service

Commit

↓

REST

↓

Payment Service

Fails

↓

Rollback Order

Inventory cannot rollback.

---

Why?

Because

@Transactional

only controls

its own TransactionManager.

It has no authority over another microservice’s transaction.

---

3. Then How Do We Solve It?

Instead of one huge transaction

Every service has

Local Transaction

Example

Order Service

Save Order

Commit

↓

Publish Event

OrderCreated

↓

Inventory Service

Reduce Stock

Commit

↓

Publish

InventoryReserved

↓

Payment Service

Charge Customer

Commit

---

If Payment Fails?

Instead of rollback

It publishes

PaymentFailed

Inventory receives

PaymentFailed

Compensation

Add Stock Back

Order receives

PaymentFailed

Compensation

Cancel Order

This is called

Saga Pattern

---

Saga = Compensation

Instead of

Rollback()

We perform

Undo Action

Example

Reserve Seat

↓

Payment Failed

↓

Release Seat

Instead of rollback.

---

4. Real Interview Example (Amazon)

Customer buys iPhone.

Order Service

Creates Order.

↓

Inventory Service

Reserves iPhone.

↓

Payment Service

Charges Card.

↓

Shipping Service

Creates Shipment.

Now suppose payment fails.

Should database rollback?

Impossible.

Shipment service already committed.

Inventory already committed.

Instead

Cancel Shipment

Release Inventory

Mark Order Failed

This is Compensation.

---

5. ACID vs Eventual Consistency

@Transactional

Immediately Consistent

Either

Everything

or

Nothing

---

Distributed Transaction (Saga)

Initially

Order Created

Inventory Reserved

Payment Pending

For a few seconds

System is inconsistent.

Eventually

Either

Payment Success

↓

Shipping

↓

Completed

OR

Payment Failed

↓

Release Inventory

↓

Cancel Order

Eventually

Everything becomes consistent.

This is called Eventual Consistency.

---

6. When Should You Use Which?

Use @Transactional when:

• Single Spring Boot application
• Single database
• Local transaction
• CRUD operations within one service

Example:

• Create Employee
• Update Balance
• Save User Profile
• Bank transfer between accounts in the same database

---

Use Distributed Transactions (Saga) when:

• Multiple microservices
• Multiple databases
• Kafka/RabbitMQ communication
• REST communication between services
• Independent deployments

Example:

• E-commerce order processing
• Flight booking
• Hotel booking
• Food delivery
• Ride booking
• Insurance claim processing

---

Interview Answer (2-Minute Version)

“@Transactional is used for local transactions within a single application and typically a single database. It ensures ACID properties by committing or rolling back all operations together. However, it cannot manage transactions across multiple microservices because each service has its own database and transaction manager. In distributed systems, we use patterns like Saga, where each service performs a local transaction and, if a later step fails, compensating actions are executed to undo the previously completed work. This provides eventual consistency instead of a single global rollback.”

---

Quick Revision

Aspect	@Transactional	Distributed Transaction (Saga)
Number of Services	1	Multiple
Number of Databases	1	Multiple
ACID Guarantee	✅ Yes	❌ No (Eventual Consistency)
Rollback	Automatic	Compensation Logic
Communication	Direct method/DB calls	REST, Kafka, RabbitMQ, etc.
Complexity	Low	High
Best For	Monolithic applications or operations within a single microservice	Microservices spanning multiple services and databases

Key takeaway: @Transactional is ideal for maintaining consistency within a single service and transactional resource. Once a business workflow spans multiple microservices or databases, a single transaction cannot cover all participants, so patterns like Saga are used to achieve eventual consistency through coordinated local transactions and compensating actions.