HerokuJeff ChaoTutorial
Kafka Streams on Heroku
Summary
Kafka Streams on Heroku shows how to organize, deploy, and scale Java stream-processing services using Kafka Streams, Apache Kafka, and the Heroku Runtime. The example contains a Text Processor that splits input from a textlines topic into words, an Aggregator that counts words in 10-second windows before writing to Postgres, and an independent Anomaly Detector that routes 10-second login-failure counts to urgent alerts or non-urgent email based on thresholds. A Gradle multi-project setup packages each service as an executable and uses a Procfile to run them as separate Heroku workers, while managed Kafka supplies the event-streaming infrastructure. Scaling is explained through Kafka partitions and Kafka Streams Stream Tasks: Stream Threads provide vertical scaling, dyno counts provide independent horizontal scaling, and Kafka Streams redistributes tasks when workers change or fail.
Context
The post addresses the provisioning, orchestration, monitoring, deployment, and scaling concerns that remain when building Kafka Streams applications, despite the library simplifying stream-processing code and avoiding separate infrastructure dependencies alongside Kafka clusters.
Approach / What changed
It uses a multi-project Gradle application with separate Kafka Streams services, executable artifacts, and Procfile worker definitions on Heroku. The example connects services through Kafka topics, uses managed Kafka and the Heroku Runtime, and scales with Stream Threads or dyno counts while Kafka Streams redistributes Stream Tasks.
Takeaways
Kafka Streams applications use partitions and Stream Tasks as their fundamental parallelism limits; a service cannot have more Stream Tasks than its topic partitions.
The example Aggregator groups words into 10-second windows and writes counts to Postgres through a custom sink processor, while noting that external-system writes are difficult to implement correctly.
Vertical scaling increases Stream Threads per instance, whereas horizontal scaling changes worker dyno counts so services can be scaled independently.
Source and freshness
- Source
- heroku.com
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.