Distributed SQL Transactions
summary
Prototype implements distributed transactions with Python + plain PostgreSQL, using a two‑phase commit and prepared transactions to move money across sharded accounts. Demo code shows a piggy‑bank example on two workers, points out 6 TB production data and a target of ~50–100x growth, and uses replication tools like Patroni and the Citus extension as real options. Coordinator persists transaction state; failures leave prepared locks and require recovery logic, so the prototype works but exposes long locks and coordinator durability trade‑offs.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 3:12Why distributed databases and Cytus
- 7:35Handling server failures with replication
- 9:01CAP theorem and replication trade-offs
- 12:15Building a distributed piggy bank
- 15:46Two-phase commit for distributed transactions
- 18:16Transaction locks and consistency challenges
- 20:46Sharding and replication questions
- 24:12Consistency trade-offs in distributed systems
- 27:04Role of the coordinator in transactions
- 29:55Maintainability and Cytus limitations
- 33:39Visibility of prepared transactions
- 34:41Demo and Q&A
related talks
38mPostgreSQL as a distributed computing platform
41mTransactions: myths, surprises and opportunities
43mDjango Transactions: Past, Present, and Future
31mSharded & Distributed Are Not the Same:
17mKeynote
01h 00mDistributed transactions implementation trade-offs
41mConcurrency, Scalability and Transactions -- Myths and Surprises
46mpg paxos Table Replication through Distributed Consensus