Kafka batch consumer partition tuning
Skill kjuhwa/skills-hub/skills/backend/kafka-batch-consumer-partition-tuning
Self-correcting knowledge corpus for Claude Code — 9 stable shape clusters, bias-correction pipeline baked into contribution flow. 47 papers, 45 techniques, 1.1k skills.
npx -y skills add kjuhwa/skills-hub --skill kafka-batch-consumer-partition-tuningAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Size Kafka partition count + max-poll-records per topic volume so heavy-processing batch consumers avoid max.poll.interval.ms breaches and maintain throughput via per-partition concurrency.
SKILL.md
2.1 KB, as published. Nobody here has run it
Kafka Batch Consumer Partition Tuning
Shape
Two knobs control whether a batch listener survives heavy load:
- Partition count per topic — scaled by volume; upper bound on listener concurrency.
max-poll-records— scaled down for heavy work sopoll()cadence stays well insidemax.poll.interval.ms.
Steps
- Classify topics by volume: high-volume (measurements, metrics) vs. low-volume (config changes, admin).
- Provision partition count accordingly (e.g.
9for high,3for low). - Listener factory:
setBatchListener(true)+setConcurrency(numPartitions)— one thread per partition. - Lower
max-poll-recordsfor heavy consumers (e.g.10). Per-poll overhead is tiny in Spring Kafka; more frequent polls beat fatter batches. AckMode.BATCH— offsets commit after each batch, not per record.setAutoStartup(false)— start containers programmatically after service-dependency checks.- Wrap key/value deserializers with
ErrorHandlingDeserializerand attach aDeadLetterPublishingRecoverer. - Expose queue/lag metrics via Actuator/Prometheus.
Counter / Caveats
- Don't over-partition low-volume topics — metadata + replication overhead with no benefit.
- Partition count is costly to shrink; size deliberately (~3× current peak, not 10×).
- I/O-bound workloads are capped at one-thread-per-partition — extra concurrency wastes threads.
- See linked knowledge entries for the project-specific rationale on batch-size and partition topology.