Reliable Serverless Needs Distributed Transactions
summary
Argues that serverless systems today cause double-charge and duplicate-shipping bugs (shows a checkout example and a real bank deposit error) because application-layer eventual consistency outpaces strong databases like Spanner and Cockroach. Proposes adding transactional context primitives so reads and mutations commit only when a function returns, accepts modest locking cost versus developer complexity, and describes a two-year-built system called Reboot that provides transactional primitives, React custom hooks, and async workflows which aim to make consistency observable to the front end.
AI-written summary · about
chapters (9)
- 0:00Introduction to Reliable Serverless and Distributed Transactions
- 0:57The Shift from Monoliths to Microservices
- 2:00Challenges with Eventual Consistency
- 3:26A Real-World Example of Checkout Function Issues
- 6:23Common Bugs in Microservices
- 9:24Event Sourcing and Durable Execution
- 16:16The Case for Transactional Contexts
- 20:10Introducing Reboot: A Solution for Transactional Primitives
- 21:39Conclusion and Call to Action
related talks
28m8 Keys for Successful Serverless Architectures
51mConfusion In The Land Of The Serverless
49mYou Don't Want Serverless
55mConfusion In The Land Of The Serverless
52mConfusion In The Land Of The Serverless
26mTransactional Serverless with DBOS
32mServerless - The Problem Reactive Was Looking For
28mServerless - the way microservices should be