Being transactional in 2019 - what does this actually mean?
summary
ACID and CAP are unpacked into concrete failure modes: snapshot isolation causes write skew (example: spouses overdraw family balance) and ANSI isolation levels map inconsistently across Postgres, MySQL and Oracle. Multi-document transactions arrive in MongoDB but use a coordinator/two-phase style that means two-phase commit blocks on coordinator failure, while Spanner uses TrueTime and Paxos to get strict serializability, and FoundationDB uses a central transaction log + deterministic replication. Kafka adds producer transactions to get exactly-once between topics for common ETL patterns.
AI-written summary · about
chapters (20)
- 0:00Introduction and speaker background
- 1:20Basics of database transactions
- 3:10Understanding isolation levels
- 6:20Snapshot isolation and anomalies
- 8:27Solutions to isolation issues
- 11:02Spring and transactional annotations
- 12:33MongoDB multi-document transactions
- 13:37Revisiting the CAP theorem
- 17:34Trade-offs in distributed systems
- 22:49Transactions in distributed databases
- 25:47Two-phase commit and alternatives
- 29:45Consensus algorithms and availability
- 31:28NewSQL systems and Spanner
- 34:42Google Spanner's hardware magic
- 36:07Deterministic database replication
- 38:19Transactions in messaging systems
- 38:41Kafka as a distributed log
- 40:30Kafka transactions use cases
- 43:40Exactly-once delivery in Kafka
- 45:28Key takeaways and resources
related talks
43mBeing Transactional in 2019 — What Does That Actually Mean?
52mTransactions: Myths, Surprises and Opportunities
41mTransactions: myths, surprises and opportunities
58mDon’t Drop ACID - Transactions in Distributed NoSQL
01h 00mDistributed transactions implementation trade-offs
01mDon't Drop ACID - Transactions in Distributed NoSQL
55mTackling transactions in Microservices applications
34mCassandra on ACID: This Changes Everything