Concurrency, Scalability and Transactions -- Myths and Surprises
summary
Shows concrete failures from concurrent handlers that read then later update the same row (order paid vs order canceled), demonstrates Postgres behavior across isolation levels and explains why a simple BEGIN/COMMIT doesn't fix races. Covers read committed, repeatable read and serializable tradeoffs: serializable prevents anomalies but causes transaction aborts and retries; advises doing reads inside transactions, using SELECT FOR UPDATE when appropriate, rolling back external side effects, and monitoring DB locks and server clocks.
AI-written summary · about
chapters (22)
- 0:00Introduction and speaker background
- 3:18Why concurrency matters today
- 7:56Complexity of large-scale systems
- 9:19Where concurrency appears in web apps
- 11:46Databases as complex concurrency engines
- 12:49What transactions really do
- 14:16Real-world transaction example
- 18:59Why simple transactions aren't enough
- 20:02Transaction isolation levels explained
- 21:29Dirty reads and their dangers
- 23:20Non-repeatable reads and phantom reads
- 26:59Serializable isolation and its costs
- 29:15Why databases don't default to serializable
- 30:40Serializable example and failure handling
- 32:04Performance impact of isolation levels
- 32:48Lock contention and side effects
- 34:12Retry storms and circuit breakers
- 34:58Monitoring and observability for databases
- 36:25Dormant issues in growing systems
- 37:48Data integrity as a core responsibility
- 38:52Coping with complexity in concurrency
- 40:21Closing and Q&A invitation
related talks
41mTransactions: myths, surprises and opportunities
45mTransactions and Concurrency Control Patterns
42mA Race To The Bottom: Database Transactions Undermining Your AppSec
28mUnderstanding Transaction Isolation for App Developers
52mTransactions: Myths, Surprises and Opportunities
58mConcurrency in Postgres
29mPutting Rails in a corner: Understanding database isolation
43mBeing Transactional in 2019 — What Does That Actually Mean?