Eventual Consistency: A Question of Time and Expectations
summary
Describes a design that keeps only the critical decision (availability and persistence) synchronous and moves follow-up work to asynchronous workers. Uses a domain-separated backend that emits a fact event when a registration is accepted, then workers handle payment, badge issuance, and email later, with patterns like commands→decisions→events, idempotence, transactional outbox, and sagas so the system tolerates slow or failed downstreams and converges to a correct state.
AI-written summary · about
chapters (10)
- 0:00Eventual consistency intro
- 1:09Critical path and sync arch
- 7:17Rethinking critical path
- 9:05New event-driven design
- 13:25Eventual consistency and time
- 19:27Time-related issues
- 24:43Introducing eventual consistency
- 27:08What must stay synchronous
- 28:52Time in the model
- 29:33Q&A
related talks
25mThe shell game called eventual consistency
01h 01mLost in transaction Strategies to manage consistency in distributed systems
30mData Consistency Patterns in Cloud Native Applications
52mEventual Consistency in a Stateful Service
34mAtomicity and Consistency Across Databases and Messaging Systems
36mLost In Transaction
27mData Consistency in Microservices Architecture
51mComplex Event Flows in Distributed Systems