Module 9: Consensus Algorithms
The Consensus Problem
How do distributed nodes agree on a single value when messages can be lost, delayed, or nodes can crash?
┌─────────────────────────────────────────────────────────────────┐ │ THE CONSENSUS PROBLEM │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Scenario: Elect a leader │ │ │ │ ┌─────┐ "I'm leader!" ┌─────┐ "I'm leader!" ┌─────┐ │ │ │ A │ ────────────────► │ B │ ◄──────────────── │ C │ │ │ └─────┘ └─────┘ └─────┘ │ │ │ │ Problem: Both A and C think they're leader (split-brain) │ │ │ │ Requirements for consensus: │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ 1. AGREEMENT: All non-faulty nodes decide same value │ │ │ │ 2. VALIDITY: Decided value was proposed by some node │ │ │ │ 3. TERMINATION: All non-faulty nodes eventually decide │ │ │ │ 4. INTEGRITY: Each node decides at most once │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ Used for: │ │ • Leader election │ │ • Distributed locks │ │ • Atomic broadcast (total order) │ │ • State machine replication │ │ │ └─────────────────────────────────────────────────────────────────┘
FLP Impossibility
┌─────────────────────────────────────────────────────────────────┐ │ FLP IMPOSSIBILITY RESULT │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Fischer, Lynch, Paterson (1985): │ │ │ │ "In an asynchronous system where even one node can fail, │ │ it is impossible to guarantee consensus will be reached." │ │ │ │ Why? │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Can't distinguish between: │ │ │ │ • Crashed node (will never respond) │ │ │ │ • Slow node (will respond eventually) │ │ │ │ │ │ │ │ If we wait forever → no termination │ │ │ │ If we don't wait → might decide without crashed node │ │ │ │ (could violate agreement later) │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ How real systems work anyway: │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ • Use timeouts (may never terminate, but usually does) │ │ │ │ • Assume partial synchrony (bound after GST) │ │ │ │ • Probabilistic guarantees (Paxos, Raft) │ │ │ │ • Human intervention for edge cases │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ FLP doesn't say consensus is impossible - │ │ just that no deterministic algorithm always terminates. │ │ │ └─────────────────────────────────────────────────────────────────┘
1. Paxos
The foundational consensus algorithm, invented by Leslie Lamport (1989).
Basic Paxos (Single-Value Consensus)
┌─────────────────────────────────────────────────────────────────┐ │ PAXOS ROLES │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ PROPOSER: │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ • Proposes values to be chosen │ │ │ │ • Drives the protocol │ │ │ │ • Usually the client or leader │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ ACCEPTOR: │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ • Votes on proposals │ │ │ │ • Stores accepted value │ │ │ │ • Forms quorums for decisions │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ LEARNER: │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ • Learns the chosen value │ │ │ │ • Doesn't participate in voting │ │ │ │ • Often the same process as proposer │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ In practice: Same node often plays all roles │ │ │ └─────────────────────────────────────────────────────────────────┘
Paxos Protocol (Two Phases)
┌─────────────────────────────────────────────────────────────────┐ │ PAXOS TWO-PHASE PROTOCOL │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ PHASE 1: PREPARE (Get permission to propose) │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ Proposer Acceptors │ │ │ │ │ A1 A2 A3 │ │ │ │ │ │ │ │ │ │ │ │ │ ─── Prepare(n) ─────►│ │ │ │ │ │ │ │ ─── Prepare(n) ───────────►│ │ │ │ │ │ │ ─── Prepare(n) ─────────────────►│ │ │ │ │ │ │ │ │ │ │ │ │ │ ◄── Promise(n, v?) ──│ │ │ │ │ │ │ │ ◄── Promise(n, v?) ────────│ │ │ │ │ │ │ ◄── Promise(n, v?) ──────────────│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ Prepare(n): "I want to use proposal number n" │ │ │ │ Promise(n, v?): "I promise not to accept < n" │ │ │ │ "Here's highest accepted value (if any)"│ │ │ │ │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ PHASE 2: ACCEPT (Propose the value) │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ Proposer Acceptors │ │ │ │ │ A1 A2 A3 │ │ │ │ │ │ │ │ │ │ │ │ │ ─── Accept(n, v) ───►│ │ │ │ │ │ │ │ ─── Accept(n, v) ─────────►│ │ │ │ │ │ │ ─── Accept(n, v) ───────────────►│ │ │ │ │ │ │ │ │ │ │ │ │ │ ◄── Accepted(n) ─────│ │ │ │ │ │ │ │ ◄── Accepted(n) ───────────│ │ │ │ │ │ │ ◄── Accepted(n) ─────────────────│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ Accept(n, v): "Accept value v with proposal n" │ │ │ │ Accepted(n): "I accepted proposal n" │ │ │ │ │ │ │ │ Value chosen when majority accepts! │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────┘
Why Paxos Works
┌─────────────────────────────────────────────────────────────────┐ │ PAXOS SAFETY GUARANTEE │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Key insight: Once a value is chosen, it cannot be changed │ │ │ │ Scenario: Value "X" chosen in round 5 │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ Round 5: Majority accepts "X" │ │ │ │ Acceptors: A1(X,5), A2(X,5), A3(-) │ │ │ │ │ │ │ │ New proposer tries round 6: │ │ │ │ 1. Sends Prepare(6) to all acceptors │ │ │ │ 2. A1 responds: Promise(6), already accepted (X,5) │ │ │ │ 3. A2 responds: Promise(6), already accepted (X,5) │ │ │ │ 4. Proposer MUST use "X" (highest accepted value) │ │ │ │ 5. Sends Accept(6, X) - same value! │ │ │ │ │ │ │ │ Any majority overlaps with previous majority! │ │ │ │ So new proposer always learns already-chosen value. │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ Quorum intersection: │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Round 5 majority Round 6 majority │ │ │ │ ┌───────────┐ ┌───────────┐ │ │ │ │ │ A1 A2 │ │ A2 A3 │ │ │ │ │ └───────────┘ └───────────┘ │ │ │ │ │ │ │ │ │ │ └───────┬──────────────┘ │ │ │ │ │ │ │ │ │ A2 in both! │ │ │ │ A2 tells round 6 about "X" │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────┘
Multi-Paxos
┌─────────────────────────────────────────────────────────────────┐ │ MULTI-PAXOS │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Basic Paxos: One value (expensive: 2 round-trips) │ │ Multi-Paxos: Sequence of values (amortized 1 round-trip) │ │ │ │ Optimization: Elect stable leader, skip Phase 1 │ │ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ Basic Paxos per value: Multi-Paxos (with leader): │ │ │ │ │ │ │ │ Phase 1 (Prepare) (Skip - leader already has │ │ │ │ ↓ permission for all slots) │ │ │ │ Phase 2 (Accept) Phase 2 only (Accept) │ │ │ │ ↓ ↓ │ │ │ │ Repeat for each value Repeat for each value │ │ │ │ │ │ │ │ 4 messages/value 2 messages/value │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ Log of chosen values: │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Slot 1: "write x=5" │ │ │ │ Slot 2: "write y=10" │ │ │ │ Slot 3: "write x=7" │ │ │ │ ... │ │ │ │ │ │ │ │ Each slot is a separate Paxos instance │ │ │ │ Leader manages slots, followers replicate │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ Used by: Chubby (Google), Spanner, many internal systems │ │ │ └─────────────────────────────────────────────────────────────────┘
2. Raft
Designed to be understandable. Same guarantees as Paxos, but simpler.
┌─────────────────────────────────────────────────────────────────┐ │ RAFT OVERVIEW │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Key differences from Paxos: │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ • Strong leader: All writes go through leader │ │ │ │ • Leader election: Explicit protocol │ │ │ │ • Log structure: Entries appended in order │ │ │ │ • Membership changes: Built-in joint consensus │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ Node states: │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ ┌──────────┐ election ┌───────────┐ │ │ │ │ │ FOLLOWER │ ──────────► │ CANDIDATE │ │ │ │ │ └────┬─────┘ timeout └─────┬─────┘ │ │ │ │ │ │ │ │ │ │ │ │ wins election │ │ │ │ │ ▼ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ ◄──────────────── │ LEADER │ │ │ │ │ │ discovers └───────────┘ │ │ │ │ │ current leader │ │ │ │ │ │ │ │ │ Start as follower │ │ │ │ If no heartbeat: become candidate │ │ │ │ If elected: become leader │ │ │ │ If find higher term: step down │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────┘
Raft Leader Election
┌─────────────────────────────────────────────────────────────────┐ │ RAFT LEADER ELECTION │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Step 1: Follower times out (no heartbeat from leader) │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Node A: "I haven't heard from leader in 300ms" │ │ │ │ "I'll become candidate for term 4" │ │ │ │ Increment term, vote for self │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ Step 2: Candidate requests votes │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ Node A (Candidate) Node B Node C │ │ │ │ │ │ │ │ │ │ │ │ RequestVote(4) ──► │ │ │ │ │ │ RequestVote(4) ────────────────► │ │ │ │ │ │ │ │ │ │ │ │ ◄── VoteGranted ─│ │ │ │ │ │ │ ◄── VoteGranted ───────────────│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ Vote rules: │ │ │ │ • Each node votes once per term │ │ │ │ • Vote only if candidate's log is "at least as good" │ │ │ │ • First-come-first-served │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ Step 3: Candidate wins majority → becomes leader │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Node A: Got 3 votes (self + B + C) out of 5 │ │ │ │ 3 > 5/2, I'm the leader! │ │ │ │ Start sending heartbeats (AppendEntries) │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ Randomized timeout prevents split votes: │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Node A timeout: 150ms │ │ │ │ Node B timeout: 230ms │ │ │ │ Node C timeout: 180ms │ │ │ │ │ │ │ │ A times out first, likely wins before others try │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────┘
Raft Log Replication
┌─────────────────────────────────────────────────────────────────┐ │ RAFT LOG REPLICATION │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Leader receives client request: │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ 1. Append to local log │ │ │ │ 2. Send AppendEntries to all followers │ │ │ │ 3. Wait for majority to acknowledge │ │ │ │ 4. Commit entry (apply to state machine) │ │ │ │ 5. Respond to client │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ Log structure: │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ Leader log: │ │ │ │ ┌─────┬─────┬─────┬─────┬─────┐ │ │ │ │ │ 1:1 │ 1:2 │ 2:3 │ 3:4 │ 3:5 │ ← (term:index) │ │ │ │ │ x=5 │ y=7 │ z=2 │ x=9 │ y=1 │ │ │ │ │ └─────┴─────┴─────┴─────┴─────┘ │ │ │ │ ↑ │ │ │ │ commitIndex │ │ │ │ │ │ │ │ Follower B log (behind): │ │ │ │ ┌─────┬─────┬─────┐ │ │ │ │ │ 1:1 │ 1:2 │ 2:3 │ │ │ │ │ │ x=5 │ y=7 │ z=2 │ │ │ │ │ └─────┴─────┴─────┘ │ │ │ │ │ │ │ │ Leader sends entries 4 and 5 to B │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ AppendEntries RPC: │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ { │ │ │ │ term: 3, │ │ │ │ leaderId: "A", │ │ │ │ prevLogIndex: 3, ← must match follower's log │ │ │ │ prevLogTerm: 2, │ │ │ │ entries: [{term:3, cmd:"x=9"}, {term:3, cmd:"y=1"}], │ │ │ │ leaderCommit: 4 │ │ │ │ } │ │ │ │ │ │ │ │ Follower checks: Do I have entry (3, term=2)? │ │ │ │ Yes → Append new entries │ │ │ │ No → Reject, leader decrements prevLogIndex │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────┘
Raft Safety
┌─────────────────────────────────────────────────────────────────┐ │ RAFT SAFETY │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ ELECTION RESTRICTION: │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ A candidate's log must be "at least as up-to-date" │ │ │ │ as any other log in the majority. │ │ │ │ │ │ │ │ Comparison: (lastLogTerm, lastLogIndex) │ │ │ │ Higher term wins │ │ │ │ Same term: longer log wins │ │ │ │ │ │ │ │ This ensures leader has all committed entries! │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ LEADER COMPLETENESS: │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ If entry committed in term T, it will be in log of │ │ │ │ all leaders in terms > T. │ │ │ │ │ │ │ │ Why: Entry committed = majority has it │ │ │ │ To win election = need majority votes │ │ │ │ Majorities overlap! │ │ │ │ At least one voter has the committed entry │ │ │ │ Candidate can't win without having that entry │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ NO SPLIT-BRAIN: │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ At most one leader per term │ │ │ │ Proof: Leader needs majority votes │ │ │ │ Each node votes once per term │ │ │ │ Can't have two majorities │ │ │ │ │ │ │ │ If old leader is partitioned: │ │ │ │ New leader elected in higher term │ │ │ │ Old leader can't commit (can't get majority) │ │ │ │ Old leader discovers new term → steps down │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────┘
3. Comparison: Paxos vs Raft
┌─────────────────────────────────────────────────────────────────┐ │ PAXOS vs RAFT │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Feature │ Paxos │ Raft │ │ ─────────────────┼──────────────────────┼──────────────────────│ │ Understandability│ Notoriously hard │ Designed to be easy │ │ Leader │ Optimization │ Required │ │ Log structure │ Out-of-order possible│ Strictly ordered │ │ Membership change│ Complex │ Joint consensus │ │ Implementations │ Many variants │ Standardized │ │ │ │ Performance: Roughly equivalent │ │ Safety: Both provide same guarantees │ │ │ │ WHEN TO USE PAXOS: │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ • You need more flexibility │ │ │ │ • Out-of-order commits are useful │ │ │ │ • Using existing Paxos-based system (Chubby, Spanner) │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ WHEN TO USE RAFT: │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ • Building new system │ │ │ │ • Team needs to understand the algorithm │ │ │ │ • Want well-documented reference implementation │ │ │ │ • Need clear membership change protocol │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ Systems using each: │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Paxos: Chubby, Spanner, Cassandra (LWT), Cosmos DB │ │ │ │ Raft: etcd, Consul, TiKV, CockroachDB, Kafka (KRaft) │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────┘
4. Practical Considerations
Handling Network Partitions
┌─────────────────────────────────────────────────────────────────┐ │ CONSENSUS DURING PARTITION │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 5-node cluster splits: │ │ │ │ ┌───────────────┐ ✗ ┌───────────────┐ │ │ │ A (leader) │ partition │ D │ │ │ │ B │ │ E │ │ │ │ C │ │ │ │ │ └───────────────┘ └───────────────┘ │ │ Majority (3) Minority (2) │ │ │ │ Majority side (A, B, C): │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ • Leader A continues │ │ │ │ • Can commit new entries (have 3/5 majority) │ │ │ │ • System fully operational │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ Minority side (D, E): │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ • Can't elect leader (only 2/5 nodes) │ │ │ │ • Reads may work (if allow stale reads) │ │ │ │ • Writes fail (can't commit without majority) │ │ │ │ • When partition heals: Catch up from majority │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ Key property: Never two leaders accepting writes │ │ │ └─────────────────────────────────────────────────────────────────┘
Performance Optimizations
┌─────────────────────────────────────────────────────────────────┐ │ CONSENSUS OPTIMIZATIONS │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 1. BATCHING │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Combine multiple client requests into one consensus │ │ │ │ │ │ │ │ Without: 1000 req/s × 2 RTT = 2000 round-trips/s │ │ │ │ With: 10 batches/s × 2 RTT = 20 round-trips/s │ │ │ │ (100 requests per batch) │ │ │ │ │ │ │ │ Trade-off: Latency increases (wait for batch) │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ 2. PIPELINING │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Don't wait for previous entry to commit │ │ │ │ │ │ │ │ Leader sends entries 5, 6, 7 in parallel │ │ │ │ Wait for all to be acknowledged │ │ │ │ Commit all at once │ │ │ │ │ │ │ │ Improves throughput significantly │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ 3. READ OPTIMIZATION │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Problem: Reads through leader adds latency │ │ │ │ │ │ │ │ Solutions: │ │ │ │ • Read from any node (may be stale) │ │ │ │ • Leader leases (leader knows it's current) │ │ │ │ • Read index (leader confirms still leader) │ │ │ │ • Follower reads with commit index check │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ 4. WITNESS REPLICAS │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Some nodes vote but don't store full data │ │ │ │ Reduces storage cost while maintaining fault tolerance │ │ │ │ │ │ │ │ Used by: CockroachDB, Spanner │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────┘
Interview Questions
Conceptual Questions
-
What is the consensus problem? Why is it important?
- Getting distributed nodes to agree on a value
- Critical for: leader election, distributed locks, atomic broadcast
- Challenging due to failures and asynchrony
-
Explain the FLP impossibility result.
- Can't guarantee consensus in async system with even one failure
- Can't distinguish slow from crashed node
- Real systems use timeouts (probabilistic termination)
-
How does Raft ensure only one leader?
- Each node votes once per term
- Leader needs majority of votes
- Can't have two majorities (they overlap)
-
What happens if the leader fails in Raft?
- Followers timeout (no heartbeat)
- One becomes candidate, requests votes
- Wins with majority, becomes new leader
- Old leader's uncommitted entries may be lost
System Design Questions
-
Design a distributed lock service using Raft.
- Log entries: ACQUIRE(lock_id, client_id, timeout)
- Leader processes acquires in order
- If lock available, grant and commit
- Client must renew before timeout
- RELEASE entries handled similarly
-
How would you handle reads in a Raft-based database?
- Option 1: All reads through leader (consistent but slow)
- Option 2: Lease-based (leader grants read lease)
- Option 3: Follower reads with read index
- Trade-off: Consistency vs latency
Summary
┌─────────────────────────────────────────────────────────────────┐ │ MODULE 9 KEY TAKEAWAYS │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 1. Consensus enables agreement in distributed systems │ │ • Leader election, locks, replicated state machines │ │ • FLP: Can't guarantee termination with failures │ │ │ │ 2. Paxos: The foundational algorithm │ │ • Two phases: Prepare and Accept │ │ • Quorum intersection ensures safety │ │ • Multi-Paxos optimizes for sequences │ │ │ │ 3. Raft: Understandable consensus │ │ • Strong leader, ordered log │ │ • Clear election and replication protocols │ │ • Same safety guarantees as Paxos │ │ │ │ 4. Both require majority (2f+1 nodes for f failures) │ │ │ │ 5. Production considerations │ │ • Batching and pipelining for throughput │ │ • Read optimization (leases, follower reads) │ │ • Careful handling of network partitions │ │ │ └─────────────────────────────────────────────────────────────────┘
Next Module: Distributed Transactions - 2PC, 3PC, and how to achieve ACID across nodes.