At Least Once
summary
Argues that distributed systems drop two‑phase commit and implement consistency in application code by breaking domains into fiefdoms, using message-based collaborations (local orchestration plus global choreography), handling failures with reservations and compensation, and accepting duplicates so we can promise at least once. Shows the Outbox pattern (transactionally write state and outgoing messages), an inbox for de‑duplication, retry/sweeper strategies, and demos an implementation with Brighter and EF Core to prove the approach works end to end.
AI-written summary · about
chapters (20)
- 0:00Introduction
- 6:49Fief Terms
- 11:19Collaborations
- 19:41Messaging
- 24:17Fiefdoms
- 25:17Collaboration
- 27:23Orchestration vs Choreography
- 30:47Cause and Effect
- 33:05tentative operations
- 34:25Saga pattern
- 34:52Messaging vs Events
- 40:34Reference Data
- 42:12Emissaries
- 43:33Messages
- 49:58Overall Model
- 51:55Brighter
- 54:30Outbox
- 57:28Payment Request
- 59:07Outbox Configuration
- 59:44Send Immediately
related talks
50mAt Least Once
01h 02mConsistency and Agreements in Distributed Systems
58mEliminating Hidden Dangers to Your Applications Patterns for Reliable Systems
53mLife Beyond Distributed Transactions: An Apostate's Implementation
46mLost in transaction? Strategies to deal with (in-)consistency in distributed systems
01h 00mLife Beyond Distributed Transactions: An Apostate's Implementation
34mAtomicity and Consistency Across Databases and Messaging Systems
01h 02mLife Beyond Distributed Transactions: An Apostate's Implementation