1. ATM
1.1. Trade-Off Between Availability and Consistency (A over C because more revenue)
1.2. Essential operations: deposit, withdrawal and balance check with key invariant: balance higher than 0
1.3. Partition handling with Stand-In Mode: allowing withdrawals up to predefined limit
2. Compensations for Mistakes
2.1. Delaying Risky Operations for Easier Recovery
2.2. Approaches to Restoring Invariants: "last writer wins"
3. 2 of 3 is Missleading
3.1. Consistency, Availability, and Partition Tolerance cant be achived simultaneously
3.2. The common interpretation that one property must always be sacrificed is an oversimplification
3.3. In practice, partitions are rare -> systems can often provide both consistency and availability
3.4. Instead of treating partitions as rare exceptions, systems should proactively detect and handle them
4. Partition Recovery
4.1. States need to be made consistent.
4.2. Errors from the partition must be compensated.
4.3. Consistency Strategies
4.3.1. Rollback/Rollforward: Replay operations from the history.
4.3.2. Conflicts: Manual resolution required (e.g., CVS).
4.3.3. Automatic Conflict Resolution: Limit operations (e.g., Google Docs).
4.4. Commutative Operations and CRDTs
4.4.1. CRDTs: Commutative, replicated data types for partition recovery.
4.4.2. Monotonic Operations: Maximum values are merged after partitions.
4.4.3. Sets for Additions and Deletions: Automatically converge.
4.5. Design decisions: Delay or prohibit certain operations during partition.
5. Cap confusion
5.1. CAP Theorem Misunderstandings
5.1.1. Availability (A) vs. Consistency (C)
5.1.2. Disconnected Operation:
5.2. Scope of Consistency
5.2.1. Primary Partition: Consistent and available within boundaries (e.g., a datacenter).
5.2.2. Wide Area: Paxos used for global consensus and durable storage.
5.2.3. Independent Subsets: Can make progress during partition, but global invariants might be lost.
5.3. Choosing CA in the "2 of 3"
5.3.1. Uncertainty of Forfeiting Partition (P): Can a system choose not to have partitions?
5.3.2. Probabilistic View: CA should mean partitions are rare compared to other system failures.
5.3.3. Partitions Within Datacenter: Less likely but still possible.
5.4. Forfeiting Consistency
5.4.1. Hidden Costs: Need to know system invariants.
5.4.2. Hidden Costs: Need to know system invariants.
5.4.3. Concurrency Problem: Similar to issues in multithreading.