Eliminating Hidden Dangers to Your Applications Patterns for Reliable Systems
summary
Claim: it is impossible to reliably make two independent state changes in a single execution context, so avoid the Dual-Writes anti-pattern. Concrete alternatives demonstrated with C# and sample code on GitHub: use Transactional Outbox with SQL Server to persist and poll, use Cosmos DB change feed/Capture for SDK-managed notifications, or use Kafka/Redis streaming for durable fan-out. Each pattern persists first, then triggers a single downstream action; sagas coordinate via orchestration or choreography, and itempotence plus retries minimize but do not eliminate commit-edge failures.
AI-written summary · about
chapters (21)
- 0:00Introduction
- 3:10Reliability Patterns
- 8:30Retry
- 12:13Multiple State Changes
- 17:16Unpredictable Errors
- 19:12Isolation Patterns
- 21:05Transactional Outbox
- 22:16Sequence Diagram
- 24:20Demos
- 26:27Advantages
- 30:21Change Data Capture
- 36:58Cosmos Change Data Capture
- 41:54Data Streaming
- 44:19Avoiding Commit Errors
- 46:08Orchestration vs Choreography
- 47:04Orchestration Workflow
- 49:05Microservices
- 51:14Never add on
- 52:27Avoid taking multiple actions
- 56:00Resources
- 57:04Questions
related talks
01h 02mAt Least Once
34mAtomicity and Consistency Across Databases and Messaging Systems
30mData Consistency Patterns in Cloud Native Applications
44mThe Simplest Way to Build Resilient Applications
01h 02mConsistency and Agreements in Distributed Systems
46mLost in transaction? Strategies to deal with (in-)consistency in distributed systems
50mAt Least Once
57mEvent driven architectures on Azure