← Back to Questions
Microservices

What is two-phase commit in Microservices?

Learn What is two-phase commit in Microservices? with simple explanations, real-time examples, interview tips and practical use cases.

What is Two-Phase Commit (2PC) in Microservices?

Two-Phase Commit (2PC) is a distributed transaction coordination protocol used in Microservices and Distributed Systems to ensure that multiple services and databases either commit a transaction together or rollback together.

It is designed to maintain:

  • Data consistency
  • Atomicity
  • Reliable distributed transactions

In simple terms:

  • Either all services successfully complete the transaction
  • OR all services rollback the transaction

Why Two-Phase Commit is Important

In Microservices Architecture:

  • Each service owns its own database
  • One business operation may involve multiple services
  • Failures can occur between services

Without proper coordination:

  • Some services may commit data
  • Other services may fail
  • System becomes inconsistent

Two-Phase Commit helps maintain consistency across all participating services.


Simple Banking Example

Suppose a banking platform contains:

  • Account Service
  • Transaction Service
  • Audit Service

A customer transfers:

₹2,00,000
    

from one account to another.

Multiple operations must happen:

  • Debit sender account
  • Credit receiver account
  • Store transaction logs

If one operation fails:

  • Entire transaction should rollback

Two-Phase Commit manages this coordination.


Problem Without 2PC

Step 1 -> Debit Sender Account SUCCESS
Step 2 -> Credit Receiver Account FAILED
    

Problem:

  • Money deducted from sender
  • Receiver did not receive money

System becomes inconsistent.


Two-Phase Commit Solution

2PC introduces:

  • A Coordinator
  • Multiple Participants

The coordinator controls transaction execution.


Main Components of 2PC

Component Description
Coordinator Controls transaction workflow
Participant Microservices/databases participating in transaction

Why It is Called Two-Phase Commit

The protocol contains:

  • Phase 1 -> Prepare Phase
  • Phase 2 -> Commit Phase

Two-Phase Commit Architecture

                Coordinator
                     |
---------------------------------------------
|                |                |
Account Service  Transaction DB   Audit Service
    

Coordinator manages all participants.


Phase 1: Prepare Phase

In this phase:

  • Coordinator asks all participants if they are ready
  • Participants prepare transaction locally
  • No final commit happens yet

Prepare Phase Banking Example

Coordinator Sends Prepare Request

Can You Commit Transaction?
    

Account Service Response

Ready
    

Amount reserved but not permanently committed.


Transaction Service Response

Ready
    

Audit Service Response

Ready
    

What Happens Internally During Prepare Phase?

  • Resources are locked
  • Changes are prepared
  • Data is not yet permanently committed

Participants wait for coordinator decision.


Phase 2: Commit Phase

If all participants respond:

Ready
    

Coordinator sends:

COMMIT
    

Commit Phase Banking Example

Coordinator -> Commit Transaction
    
  • Sender account debited
  • Receiver account credited
  • Audit logs stored

Transaction successfully completes.


Rollback Scenario Example

Suppose:

  • Account Service -> Ready
  • Transaction Service -> Failed
  • Audit Service -> Ready

Coordinator sends:

ROLLBACK
    

All participants rollback changes.


Complete 2PC Banking Flow

Customer Transfer Request
          |
Coordinator Starts Transaction
          |
Prepare Phase
          |
All Services Ready?
          |
YES ------------------> Commit Phase
NO -------------------> Rollback Phase
    

Detailed Real-Time Banking Example

Step 1: Customer Transfers Money

Transfer ₹2,00,000
    

Step 2: Coordinator Initiates Prepare Phase

Coordinator asks:

Can You Commit?
    

Step 3: Account Service Reserves Amount

Reserve ₹2,00,000
    

But not permanently deducted yet.


Step 4: Receiver Account Prepared

Prepare Credit ₹2,00,000
    

Step 5: Audit Logs Prepared

Prepare Audit Entry
    

Step 6: All Participants Respond READY

READY
    

Step 7: Coordinator Sends COMMIT

COMMIT TRANSACTION
    

Final changes become permanent.


Advantages of Two-Phase Commit

  • Strong consistency
  • Atomic distributed transactions
  • Reliable transaction coordination
  • Automatic rollback support

Strong Consistency Example

All banking systems always show:

  • Correct balances
  • Correct transaction history
  • No partial updates

Major Problems with Two-Phase Commit

  • Distributed locking
  • Performance issues
  • Reduced scalability
  • Coordinator bottleneck
  • Blocking transactions

What is Distributed Locking?

During prepare phase:

  • Resources remain locked
  • Other transactions must wait

Example:

Sender Account Locked
    

until coordinator decides commit or rollback.


Performance Problem Example

Suppose:

1 Million Banking Transactions Per Minute
    

Distributed locking can severely slow down the system.


Coordinator Failure Problem

Suppose coordinator crashes after prepare phase.

Participants remain:

  • Waiting
  • Locked
  • Unable to proceed

This is called:

Blocking Problem
    

Why Modern Microservices Avoid 2PC

Modern cloud-native systems prioritize:

  • Scalability
  • Availability
  • Fault tolerance

Two-Phase Commit reduces scalability because of distributed locking and synchronous coordination.


Modern Alternative: Saga Pattern

Most microservices architectures prefer:

Saga Pattern
    

instead of 2PC because:

  • No distributed locking
  • Better scalability
  • Asynchronous communication
  • Event-driven architecture support

2PC vs Saga Pattern

Feature Two-Phase Commit Saga Pattern
Consistency Strong Consistency Eventual Consistency
Scalability Lower Higher
Communication Synchronous Asynchronous
Distributed Locking Yes No

Technologies Supporting 2PC

  • JTA (Java Transaction API)
  • XA Transactions
  • Atomikos
  • Narayana
  • Bitronix

Spring Boot Example

@Transactional

public void transferMoney() {

    debitAccount();

    creditAccount();

}
    

In distributed systems, XA transaction managers coordinate this process.


Real-Time Use Cases

Banking Systems

  • Fund transfers
  • ATM transactions
  • Settlement systems

Financial Systems

  • Stock trading
  • Payment gateways
  • Transaction processing

Insurance Platforms

  • Claim settlements
  • Policy updates
  • Premium processing

Challenges of Two-Phase Commit

  • Complex distributed coordination
  • Blocking problems
  • Network latency
  • Reduced system throughput
  • Scalability limitations

Best Practices

  • Use 2PC only when strong consistency is mandatory
  • Prefer Saga Pattern for scalable microservices
  • Minimize distributed locking duration
  • Implement proper timeout handling
  • Monitor coordinator health carefully

Professional Interview Answer

Two-Phase Commit (2PC) is a distributed transaction coordination protocol used in Microservices and Distributed Systems to ensure that multiple services either commit or rollback a transaction together. It contains two phases: Prepare Phase and Commit Phase. During the prepare phase, all participants confirm readiness. During the commit phase, the coordinator either commits or rolls back the transaction globally. Although 2PC provides strong consistency, it introduces distributed locking, blocking issues, and scalability limitations. Therefore modern microservices architectures often prefer Saga Pattern and eventual consistency approaches instead of 2PC.


Summary

Two-Phase Commit is one of the most important distributed transaction protocols in distributed systems and enterprise applications.

It ensures strong consistency across multiple services and databases by coordinating transactions using prepare and commit phases.

Banking systems, financial platforms, and enterprise transaction systems historically relied heavily on 2PC for maintaining consistency.

However, modern cloud-native microservices architectures often prefer Saga Pattern and eventual consistency because of better scalability and fault tolerance.

Why this Microservices question is important?

This interview question helps candidates understand real-time backend development concepts, practical problem solving, coding fundamentals, system design basics and production-ready application behavior.

Practice this question carefully for Java backend roles, Spring Boot developer interviews, microservices interviews, company interviews and full-stack developer preparation.

About the Author

Naresh Kumar is a Senior Java Backend Engineer with experience building enterprise applications using Java, Spring Boot, Microservices, Docker, Kubernetes and Cloud technologies.