Study Confluent CCDAK Batching and Throughput: key concepts, common traps, and exam decision cues.
On this page
This lesson is about tuning without losing the thread of correctness. The exam often gives you a performance problem and watches whether you can optimize it without quietly breaking ordering or delivery expectations.
Throughput chooser
Goal
Strongest first fit
lower latency
smaller batches and less linger
higher throughput
larger batches, compression, and better network efficiency
preserve per-entity ordering
stable key partitioning
reduce hot partitions
rethink key distribution before scaling blindly
What the exam is really testing
If the scenario shows…
Strong reading
latency complaint
batching and linger trade-off may matter
network cost or broker load
compression and batching may matter
skewed partition load
key and partitioning behavior may matter
“more throughput” request
semantics should still be protected first
Common traps
Trap
Better rule
optimizing throughput without checking ordering needs
partition behavior may be the real constraint
blaming Kafka when one hot key is the real problem
skew often starts in key design
assuming compression changes delivery semantics
it usually changes efficiency, not correctness
Decision order that usually wins
Decide whether the problem is latency, throughput, or hot-partition skew before tuning producer knobs.
If the goal is efficiency, batching and compression are usually earlier levers than semantics-changing settings.
If ordering for one entity matters, preserve stable partition routing before chasing raw throughput.
If one partition is overloaded, inspect key distribution before scaling the rest of the system.