Return of the Transaction King
summary
Claims that FaunaDB gives ACID transactions at global scale without GPS atomic clocks and shows Scala examples using its functional query language to create classes, indexes and refs, run multi-read/modify/write transactions inside a single functional scope, and atomically update balances while writing an event log. Implementation details include an epoch-based global resolution over a Raft-replicated transaction log, optimistic reads for read-only batches, and explicit index-driven queries that return refs before get and update. Examples demonstrate preventing double-spend and enforcing serializable order across regions.
AI-written summary · about
chapters (21)
- 0:00Introduction
- 1:05ACID transactions history
- 2:27CAP theorem and trade-offs
- 3:52Event sourcing and use cases
- 5:35Event sourcing limitations
- 7:58Strong consistency explained
- 10:02Write skew and consistency problems
- 11:26Application-tier consistency patterns
- 13:55Microservices complexity
- 14:42Why ACID transactions matter
- 15:24Return of transaction King
- 16:49New databases with strong consistency
- 17:52Benefits of transactions
- 19:15CAP theorem reconsidered
- 20:59Google Spanner overview
- 23:47CockroachDB and FaunaDB
- 24:49FaunaDB architecture
- 27:19FaunaDB features
- 30:51Code demo introduction
- 38:36Bank transfer example
- 40:01Q&A
related talks
24mConsistency without Clocks: The FaunaDB Distributed Transaction Protocol
47mBeing transactional in 2019 - what does this actually mean?
46mBeyond Eventual Consistency
58mDon’t Drop ACID - Transactions in Distributed NoSQL
01mDon't Drop ACID - Transactions in Distributed NoSQL
41mTransactions: myths, surprises and opportunities
52mTransactions: Myths, Surprises and Opportunities
37m11 insights after 11 years with the functional database Datomic
