Subtracks & Tasks
Two-Phase Commit
Implement Two-Phase Commit
Implement 2PC: Phase 1 sends PREPARE, collects votes. Phase 2 sends COMMIT if all YES, else ABORT....
Handle Coordinator Failure
Handle coordinator failures: log PREPARE before sending, log COMMIT/ABORT decision, recover from log....
Implement Three-Phase Commit
3PC adds PRE-COMMIT phase. If coordinator fails after PRE-COMMIT, participants can commit safely....
Implement Saga Pattern
Sagas: sequence of local transactions with compensations. On failure, compensate in reverse order....
Build Transactional Key-Value Store
Transactional KV: begin, read, write, commit/abort. Use 2PC for cross-shard transactions....
Three-Phase Commit (3PC)
Implement Three-Phase Commit Protocol
Three-Phase Commit (3PC) adds an extra phase to 2PC to reduce blocking scenarios. The third phase (`PreCommit`) ensures participants know a commit is ...
Show How 3PC Unblocks 2PC Scenarios
The key advantage of 3PC over 2PC is that it unblocks one of 2PC's blocking scenarios. When the coordinator crashes after sending `PreCommit`, partici...
Show 3PC Blocking Under Network Partition
While 3PC improves on 2PC, it still has blocking scenarios. The key limitation: if a network partition occurs before `PreCommit`, participants may not...
Compare 2PC vs 3PC Protocols
Understanding the trade-offs between 2PC and 3PC helps choose the right protocol for your use case. **Message complexity**: ``` 2PC (happy path): P...
Implement Paxos Commit Protocol
Paxos Commit replaces the single coordinator with a Paxos consensus group. Each participant's commit decision is reached through Paxos, eliminating th...
Saga Pattern
Implement Saga Pattern with Compensating Transactions
The Saga pattern manages long-running transactions by breaking them into a sequence of local transactions with compensating actions for rollback. Unli...
Implement Choreography-Based Saga
In a choreography-based saga, there is no central coordinator. Each service listens for events and triggers the next step by publishing its own events...
Implement Orchestration-Based Saga
In an orchestration-based saga, a central orchestrator manages the saga lifecycle. It sends commands to services, tracks completion, and initiates com...
Implement Idempotency in Sagas
Idempotency ensures that retrying saga steps doesn't cause duplicate operations like double-charging payments. **Idempotency key**: Each saga step i...
Implement E-Commerce Checkout Saga
Implement a complete e-commerce checkout saga with inventory, payment, and shipping services. This demonstrates the saga pattern in a realistic scenar...
Interview Prep
Common interview questions for Distributed Systems Engineer roles that map directly to what you build in this track. Click any question to reveal the model answer.
Questions are representative of real interview patterns. Model answers are starting points — adapt them with your own experience and the specific context of the interview.
Common Mistakes
The top 5 mistakes builders make in this track — and exactly how to fix them. Click any mistake to see the root cause and the correct approach.
Comparison Mode
Side-by-side comparisons of the approaches, algorithms, and trade-offs you encounter in this track. Expand any comparison to see a detailed breakdown.
Concepts Covered
Prerequisites
It is recommended to complete the previous tracks before starting this one. Concepts build progressively throughout the curriculum.
Rabbit Holes
For when you want to go deeper. Curated papers, posts, and talks beyond what this track covers.
Dynamo: Amazon's Highly Available Key-Value Store
DeCandia et al., 2007. The paper that defined sloppy quorums, vector clocks, and hinted handoff. Reading it after implementing coordinator logic makes every design choice legible.
Two-Phase Commit and Beyond
A practitioner's guide to 2PC: what it guarantees, where it fails (coordinator crash after prepare), and why it has been partially replaced by Saga patterns in modern microservices.
Saga Pattern (Original Paper)
Garcia-Molina and Salem, 1987. The original Sagas paper. Long-lived transactions that compose compensating transactions instead of locking are the alternative to 2PC that microservices architectures prefer.
Martin Kleppmann on Distributed Transactions
A clear mapping from isolation levels to what anomalies they prevent. Understanding this is necessary before you can reason about whether your coordinator is providing the guarantees your application needs.