kattlo-cli VS parallel-consumer

Check it out the released features and what is coming at https://github.com/kattlo/kattlo-cli

Check out the parallel consumer: https://github.com/confluentinc/parallel-consumer

It processes unrelated keys in parallel within a partition. It has to track what offsets have been processed between the last committed offset of the partition and the tip (i.e. only what's currently processed out of order). When it commits, it saves this state in the commit metadata highly compressed.

Most of the time, it was only processing a small number of records out of order so this bookkeeping was insignificant, but if one key gets stuck, it would scale to at least 100,000 offsets ahead, at which point enough alarms would go off that we would do something. That's definitely a huge improvement to head of line blocking.

Hi everyone, my name is Daniel and I run a website called Rock the JVM [1]. It's a popular site and blog for Scala, and we've recently started to create guides and materials for other libraries and languages. This video is about - maximizing producer throughput - minimizing producer latency - running multiple consumers vs number of partitions, analyzing parallelism - parallel consumers [2] for 1000x perf increase vs 1x single-threaded consumer I also have written forms of all videos as long-form blog posts, and you can find the written guide here [3]. I hope you like it - let me know if you need anything or have any questions! [1] https://rockthejvm.com [2] https://github.com/confluentinc/parallel-consumer [3] https://blog.rockthejvm.com/optimizing-kafka-clients-a-hands-on-guide/

So we want to maximize parallelism while keeping DLQ style error handling and stability. We want to send messages to DLQs if any error happens and we don't want any message to be unprocessed and still be committed. I know there are Confluent Parallel Consumer, Greyhound and an article about Multi-Threaded Messaging with Kafka. But I'm not sure if they are ready for production.

I haven’t used Faust, but it should be fine for your use case if you decide not to use the http sink connector. If you are open to Java, the parallel consumer library will have MUCH better performance because the http requests won’t block. It even aims to provide automatic dead letter queue handling sometime in the future, which you mentioned you need.

Interesting. I think your use case might be well suited for the parallel consumer — https://github.com/confluentinc/parallel-consumer

Take a look at Confluent's Parallel Consumer library, it will handle this sort of scenario for you: https://github.com/confluentinc/parallel-consumer (disclaimer: I'm the author)