Top Mistakes When Writing Reactive Applications
summary
Covers concrete mistakes and fixes for Akka systems: Java serialization bloats footprints and caused a client to wait ~1 minute for persistent actors, so replace Java serialization with Kryo, Protobuf or JSON; use supervision with BackoffSupervisor (initial 3s, cap 30s, randomFactor 0.2) to avoid restart storms; implement graceful cluster shutdown via a coordinator or the coordinated shutdown extension; avoid 2PC, prefer the Saga pattern or eventual consistency; use hedging/ti requests to cut long tails (Google reported 40% drop in 99.9p); enable split brain resolver (SBR) and monitoring (Cinnamon/Kamon).
AI-written summary · about
chapters (29)
- 0:00Intro
- 1:17Actors vs Futures
- 1:47Pick the Right Tool for The Job
- 3:28Actor Use Cases
- 4:05Future Use Cases
- 4:33Avoid Java Serialization
- 4:50Sending Data Through Network
- 5:22Persisting Data
- 5:53Java Serialization - Round Trip
- 6:09Java Serialization - Footprint
- 6:37Java Serialization Implementation
- 8:44Binary formats Schema-less
- 10:29Flat Actor Hierarchies
- 10:52The Actor Hierarchy
- 12:58Two Different Battles to Win
- 13:35Errors & Failures
- 14:43Error Kernel Pattern
- 15:19Backoff Supervisor
- 18:50Graceful Shutdown
- 19:21High-level Procedure
- 20:46Integration with Sharded Actors
- 21:27CoordinatedShutdown Extension
- 23:49Distributed Transactions
- 24:59Two-phase commit (2PC)
- 25:58Saga Pattern
- 29:32Investigating Longtail Latencies
- 30:20Tolerating Longtail Latencies
- 32:30Quick Tips
- 38:11Questions
related talks
50mThe Zen of Akka
48mThe Zen of Akka
40mReactive programming: lessons learned
44mDeath to Latency: Building Reactive, Cloud Native Apps with Akka NET
48mReactive for the Impatient
52mTesting Reactive Apps
01h 11mReactive Architecture Patterns Debate
58mDeath to Latency: Building Reactive, Cloud Native Apps with Akka.NET