Distributed transactions implementation trade-offs
summary
Explains why ACID needs careful engineering in sharded, replicated systems: two-phase commit blocks on coordinator failure and requires manual recovery; leader-based replication forces writes through a leader and leader election can take ~10s, causing brief unavailability; Spanner-style designs use a TrueTime commit-wait (GPS/clock sync plus wait) to get external consistency but add 100ms+ cross-datacenter latency; hotspots and global indexes blow up performance (benchmarks move from ~100ms to multiple seconds). Advises configuring durability, testing with real peak workloads, and reading DB docs.
AI-written summary · about
chapters (10)
- 0:00Introduction
- 1:50What is a transaction
- 8:28Transaction isolation levels
- 15:04Commit log role
- 21:49Distributed sum calculation issues
- 27:28High availability and replication
- 38:38Two-phase commit
- 44:17Time sync problems
- 51:16Performance versus consistency
- 57:36Database tuning for transactions
related talks
28mPractical Approaches To Scaling Distributed Transactions
47mBeing transactional in 2019 - what does this actually mean?
31mSharded & Distributed Are Not the Same:
01mDon't Drop ACID - Transactions in Distributed NoSQL
24mDistributed Transactions at Scale in Amazon DynamoDB
52mTransactions: Myths, Surprises and Opportunities
01h 14mThe hitchhiker's guide to distributed transactions
13mThe ACID BASE Conundrum