What If We've Been Scaling Stream Processing Wrong All Along
summary
Argues that default horizontal distribution is often needless and builds a single-node alternative preserving Kafka Streams DSL, implementing Flink-like exactly-once via epoch barriers and Kafka transactions, running topology on Java virtual threads from Project Loom and RocksDB state stores. Removes repartition topics and serialization/network hops. On an 8‑core VM it hits ~124k ops/sec with 1KB records (up to ~2M ops for tiny payloads), shows up to 13× lower P99 tail latency, 3.5–4× less CPU and up to 9× less memory, with faster restores; limits are single‑machine caps and single‑producer epoch bottlenecks.
AI-written summary · about
chapters (7)
- 0:00Introduction and background
- 2:59Current stream processing challenges
- 12:36Rethinking scalability defaults
- 13:40New vertical scaling architecture
- 25:20Benchmark methodology and results
- 31:48Real-world scalability limits
- 32:51Q&A session
related talks
42mStream Processing with Apache Flink
35mStreams Must Flow: Fault-tolerant streams processing apps on Kubernetes
46mKeep it going — How to reliably and efficiently operate Apache Flink
42mPrinciples and Patterns for Streaming Data Analysis
40mDeploying Kafka Streams Applications...
37mStateful Stream Processing with Apache Flink 1.5 and beyond
13mScaling Kafka on Kubernetes
32mScaling your Kafka streaming pipeline....
