We want to ensure that all parties to a transaction are consistent. In a distributed system two-phase commit becomes a barrier to scaling. Instead we rely on eventual consistency. But for an even driven architecture, what does "relying on eventual consistency" mean in practice?
Drawing on Pat Helland's paper "Life Beyond Distributed Transactions", in this presentation we will look at:
- The two approaches we can take towards ensuring eventual consistency: choreography and orchestration, and the trade off between them.
- Why asynchronous approaches are more reliable.
- What to do if things go wrong or compensation, and the different strategies we have from retry to reservation.
- How we deal with stale data.
- Why we can only ever promise "at least once", and how we offer "at least once."
Finally, we will demo the Outbox, using the .NET OSS library Brighter and EF Core, to show how you can ensure "at least once".
Check out more of our featured speakers and talks at
[ Ссылка ]
[ Ссылка ]
