Kafka Streams and Flink are built to spread work across machines. What could a stream processor do differently if it gave up scale-out altogether? We built StoatFlow to find out.

On a stateful join with more than ten RocksDB stores, running under exactly-once on the same 8-vCPU machine, the difference is substantial: 322 milliseconds of P99 latency against tuned Kafka Streams’ 3.4 seconds and Flink’s 5.4 seconds, using less CPU and a fifth and an eighth of their memory respectively. The interesting part is what the architecture removes to get there.

This talk follows a record through a stream processor that keeps the Kafka Streams DSL but replaces the execution model underneath it. One consumer reads every partition. Keys map onto parallel lanes inside the JVM, preserving per-key order without tying parallelism to partition count. Re-keying crosses an in-memory queue instead of a Kafka repartition topic. RocksDB state and Kafka transactions meet at commit barriers that provide exactly-once processing without coordinating a cluster.

The new architecture also delivers a new 'on-barrier' emission mode: emitting a correct answer at every commit, which both Kafka Streams and Flink lack.

Giving up scale-out also positively changes operations. A rolling deploy pauses processing for about 0.4 seconds, with nothing reprocessed under exactly-once, and losing the node costs about 8.5 seconds while the standby takes over.

There are limits. Tuned Kafka Streams uses less CPU on simple stateless transforms. The measured throughput ceiling is ultimately bound by the network (which is not low on modern hardware).

You’ll leave with a concrete alternative to distributed-by-default stream processing, an understanding of how its guarantees work, and the questions to ask before choosing scale-out.