Reliable Messaging in the World of Actors
summary
Actor frameworks default to at-most-once delivery (Akka.NET, Orleans) for performance, so the system moves durable guarantees into business logic: RabbitMQ/Azure Service Bus provide the entrance, long uploads (sometimes 24-hour files) force splitting work, and earlier designs (four versions) that tried acknowledgements inside actors fail. Current solution persists intent in an event journal, uses the outbox pattern and desired-state reconciliation to compute deltas and retry idempotent operations until the external state matches the recorded desired state.
AI-written summary · about
chapters (13)
- 0:00Intro
- 4:44How to provide message handling guarantee?
- 8:53Can we run a reliable system with at-most-once message delivery?
- 11:20Don't pay for the ferryman version 1
- 17:44Don't pay for the ferryman version 2
- 19:54Don't pay for the ferryman version 3
- 22:53Don't pay for the ferryman version 4
- 28:34Important assumption: Idempotency
- 30:31But actors are reactive
- 33:23Main lesson
- 33:53Rant about workflow engines & saga managers
- 36:52Conclusion
- 37:47Outro
related talks
58mDeath to Latency: Building Reactive, Cloud Native Apps with Akka.NET
01h 11mReactive Architecture Patterns Debate
32mAdopting Actors... an epic tale of loss and learning
48mThe Zen of Akka
46mAkka Streams & Reactive Streams in action
50mThe Zen of Akka
44mDeath to Latency: Building Reactive, Cloud Native Apps with Akka NET
33mThe Actor Model, Behind the Scenes