Reactive programming lessons learned
summary
Experience with Reactor (Mono/Flux) shows reactive systems handle C10K/C100K style loads—tens of thousands of concurrent connections on a single node—but require deep expertise and raise maintenance costs. A simple shopping-cart flow becomes nested flatMap chains; debugging loses useful stack traces and timeouts lack context. Operational quirks appear: Tomcat default 100 threads with 100ms service gives ~1,000 req/s (Little’s Law), Reactor’s maxConcurrency=128 bursts traffic, and an ActiveMQ blocking callback once exhausts JDBC pools until the broker restart. Mono/Flux
AI-written summary · about
chapters (17)
- 0:00Introduction to reactive pitfalls
- 1:09Reactive programming risks
- 6:08Simple app to reactive mess
- 13:12Domain-driven design clash
- 17:34Measuring code quality
- 22:05Framework transparency
- 23:54Cost of reactive systems
- 31:20Are you Netflix scale?
- 32:23Little's Law explained
- 35:58Human vs hardware trade-off
- 36:40Maintenance nightmare
- 41:57Stack traces in reactive
- 46:11Best reactive practices
- 50:22Monitoring reactive systems
- 52:34Timing in reactive code
- 53:59Java syntax limitations
- 55:45When reactive shines
