Study Confluent CCDAK Rebalances and Lag: key concepts, common traps, and exam decision cues.
On this page
This lesson is where many consumer bugs show up. The exam wants you to see whether the problem is too much backlog, unstable membership, or application work that is taking too long for the consumer to stay healthy.
Consumer-health chooser
Symptom
Strongest first focus
lag rising steadily
processing speed, partition count, or downstream bottleneck
frequent rebalances
liveness settings, processing time, and group stability
duplicate handling after restart
commit timing and handler idempotence
slow record handling
poll cadence and processing design
What the exam is really testing
If the scenario shows…
Strong reading
consumers keep rejoining
liveness and rebalance behavior matter
backlog but stable group
throughput or downstream work may be the real constraint
long processing within the poll loop
liveness boundary is under test
poison message or repeated failure
failure-handling strategy is under test
Common traps
Trap
Better rule
blaming brokers first for every lag problem
group design and processing speed often matter more
treating rebalances as harmless background events
frequent rebalances can destabilize processing
assuming “add more consumers” fixes everything
partition count and downstream systems still bound throughput
Decision order that usually wins
Separate backlog from membership instability before proposing a fix.
If rebalances are frequent, inspect liveness and long processing inside the poll loop first.
If the group is stable but lag rises, inspect throughput, partition count, and downstream work next.
Treat poison messages and repeated failures as failure-handling design issues, not just as broker problems.