System Design

Distributed Transactions Part 2: The Blocking Trap

A deep dive into 2PC and 3PC. Learn why atomic commitment protocols often lead to cascading failures in high-traffic systems.

Sachin Sarawgi·April 20, 2026·1 min read
#distributed-transactions#2pc#3pc#scalability
Learning Track

Distributed Transactions Mastery

Completed0%
View all tracks →
On This PageOpen
Back to top

Part 2: The Blocking Trap

Two-Phase Commit (2PC) is the most famous distributed transaction protocol, but it is rarely used in high-scale cloud environments. Why? Because it is blocking.

1. The Handshake

2PC involves a Coordinator and Participants.

  1. Prepare: Coordinator asks if everyone can commit.
  2. Commit: If everyone says yes, the coordinator sends the commit signal.

2. The Failure Mode

If the coordinator crashes after the "Prepare" phase, every participant remains locked. They cannot release their database locks because they don't know if the final result was a Commit or an Abort. This "Wait State" is the killer of throughput.

Next: Part 3: The Saga Pattern

📚

Recommended Resources

Designing Data-Intensive ApplicationsBest Seller

The definitive guide to building scalable, reliable distributed systems by Martin Kleppmann.

View on Amazon →
Kafka: The Definitive GuideEditor's Pick

Real-time data and stream processing by Confluent engineers.

View on Amazon →
Apache Kafka Series on Udemy

Hands-on Kafka course covering producers, consumers, Kafka Streams, and Connect.

View Course →

Practical engineering notes

Get the next backend guide in your inbox

One useful note when a new deep dive is published: system design tradeoffs, Java production lessons, Kafka debugging, database patterns, and AI infrastructure.

No spam. Just practical notes you can use at work.

Sachin Sarawgi

Written by

Sachin Sarawgi

Engineering Manager and backend engineer with 10+ years building distributed systems across fintech, enterprise SaaS, and startups. CodeSprintPro is where I write practical guides on system design, Java, Kafka, databases, AI infrastructure, and production reliability.

LinkedInGitHubMediumMore articles

Found this useful? Share it:

Share on X/TwitterShare on LinkedIn

Related Articles

System Design

gRPC vs REST: The Decision-Maker's Guide for Backend Architecture

gRPC vs REST: Which One for Your Microservices? In modern backend architecture, how services talk is as important as what they say. Choosing between REST and gRPC isn't just about syntax; it's about the trade-off between…

Apr 20, 20262 min read
#grpc#rest#api-design
System Design

gRPC vs REST: A Decision-Maker's Guide for Backend Architecture

gRPC vs REST: Which One for Your Microservices? > Prerequisite: Before diving into protocols, ensure you understand the fundamentals of Load Balancing and API Idempotency. Choosing between REST and gRPC is one of the mos…

Apr 20, 20263 min read
#grpc#rest#api-design
System Design

API Pagination at Scale: Why OFFSET 100,000 is a Database Killer

API Pagination at Scale: Moving Beyond OFFSET Designing a paginated API seems simple: just use . This works perfectly for the first few pages. However, once your users reach page 5,000, your database performance will fal…

Apr 20, 20262 min read
#api-design#pagination#sql
← Back to all articles