Asychronous design with Spring and RTI: 1M events per second
summary
Claimed architecture reaches million‑event annual peaks with a steady baseline near 100k events/sec and typical bursts; actual gains come from specific optimizations: replacing random UUIDs, using compiled SpEL, switching channels to mutable messages and integration chains, moving to reactor stream batching for large I/O payloads, and leveraging GemFire micro‑batching and RabbitMQ blobs. Result: dramatic CPU drop (80% → ~5–10%) and half‑million event test runs in seconds after warmup, at the cost of batching trade‑offs and selective data discard under overload.
AI-written summary · about
chapters (21)
- 0:00Intro
- 0:35What is this all about?
- 1:32Dogfood
- 2:08Questions for you
- 3:14What is RTI?
- 6:29Input Data Rates
- 7:18Load Characteristics
- 8:11More statistics...
- 11:49Architectural Challenges
- 13:48Ingester Architecture
- 15:49Analytics Architecture
- 18:34Solution #1 -'Naïve' proof of concept
- 19:31Solution #1 results
- 20:38Solution #2 - Use interfaces
- 21:37Solution #2 results
- 22:52Solution N
- 23:57Working version
- 24:38Spring Improvements
- 26:39Spring Integration
- 43:09Spring Expression Language
- 48:58Reactor
related talks
37mReactive Architecture on AWS: from 0 to 1.6M events/minute
45mMicro Services and Events: Friends or Foes?
57mReliability Nirvana
44mKeynote: Erlang Powered Rabbits
54mReacting to an Event-Driven World
47mMonolith to Microserv. at 20M+ requests per second: Latency and Scale Challenges
50mProcessing Billions of Events in Real-Time with Heron
45mFaster or better designed? Choose any two!