What is a Reactive Application?
summary
Defines reactive as a concrete stack: message-driven systems with actor-style isolation (Erlang/Akka), histograms for every request (HDR), and backpressure by bounding queues and rejecting excess. Cites hardware shift (Haswell EP 18 cores) and recommends keeping CPU utilization around 60–70% to avoid latency blowups, avoiding synchronous RPC in favor of async pipelines, using bulkheads and let it crash restart/supervision patterns, and combining reactive elasticity with metrics, circuit breakers and event-sourced logs.
AI-written summary · about
chapters (19)
- 0:00Start
- 4:59Responsive Resilient Elastic
- 8:292. Offer good Service Times
- 12:35Limit queue lengths to control response times
- 14:39Shared mutable state is the crystal meth of concurrent systems
- 15:56Synchronous RPC is the crack cocaine of distributed programming
- 26:181. Isolate, 2. Make faults observable, 3. Restart
- 29:13KEEP CALM AND LET IT CRASH
- 30:12Why do we need to be Elastic?
- 32:45Scalability vs Performance
- 33:55Scale OUT
- 35:21be ASYNC
- 37:34location TRANSPARENCY
- 38:05obtain METRICS
- 38:26reactive ELASTICITY
- 38:55predictive ELASTICITY
- 39:53Message Driven
- 41:14Forced Decoupling & Separation of Concerns
- 49:05Even traditional blocking operations can be decoupled
related talks
44mReacting to the future of application architecture
27mFour Principles of Reactive Architectures
01h 11mReactive Architecture Patterns Debate
50mThe reactive landscape
12mReactive architecture, design, and programming
03mAm I only streaming? Thinking reactive
35m5 Reasons to Use Reactive Programming if You Are Not eBay
54mReacting to an Event-Driven World