At Least Once
summary
Compares orchestration vs choreography for eventual consistency, argues fiefdoms own local workflow and use messaging for request/reply and event-driven reference data, and claims two-phase commit is replaced by transactional outbox + background delivery. Demo uses the .NET OSS library Brighter with EF Core showing handler code, inbox middleware for duplicates, transactional writes to entity + outbox, retries/reservations and an at least once delivery guarantee that requires idempotence.
AI-written summary · about
chapters (17)
- 0:00Introduction and welcome
- 1:51About the speaker and topic
- 3:17Pat Helland’s ideas on fiefdoms
- 7:29What is a fiefdom?
- 10:00Emissaries and collaborations
- 11:45How collaborations work
- 15:22Synchronous vs messaging models
- 18:11Activities and state management
- 21:26Correlation IDs and workflows
- 23:59Orchestration vs choreography
- 27:31Causality in messaging
- 31:49Commands vs events
- 33:13Reference data and event sourcing
- 36:06Emissaries and offline clients
- 38:57Outbox pattern for consistency
- 44:31Code example and implementation
- 48:22Q&A and closing
related talks
01h 02mAt Least Once
01h 02mMessaging Patterns for Modern Software Solutions
01h 01mBeyond Pub/Sub - Advanced Messaging Patterns
32mBalancing Choreography & Orchestration
38mChoreography vs Orchestration in long running asynchronous processes
01h 02mConsistency and Agreements in Distributed Systems
53mLife Beyond Distributed Transactions: An Apostate's Implementation
57mEvent driven architectures on Azure