Slow Consumer
partialContainedcapacity failure · isolated propagation
Blast Radius
0%
0/21 nodes
Time to Detect
2–10 minutes with per-partition lag monitoring. Rebalance events are detectable within seconds in Kafka broker metrics. The root cause (GC on a specific JVM) may take longer to identify if consumer-instance-level metrics are not available.
Preventive Mitigations
2
Confidence
StrongFailure Cascade
(no topology nodes mapped for this failure mode)
This failure mode is referenced in the scenario knowledge but has no connected topology nodes. Impact scope is scenario-level, all components should be considered potentially affected.
Severity at this step: partial
Detection Signals
Recovery time estimate: 2–10 minutes once the slow consumer instance is identified and restarted or replaced. With cooperative rebalancing, partition reassignment completes without stopping other consumers. Without it, each rebalance adds 3–30 seconds of group-wide stoppage.
Mitigation Checklist(2 preventive, 3 reactive)
Configure G1GC or ZGC with a max pause time target below heartbeat timeout: -XX:MaxGCPauseMillis=500 and session.timeout.ms=10000. ZGC achieves <10ms pauses for most heap sizes. Alternatively, increase session.timeout.ms to 120,000ms to tolerate longer GC pauses, accepting slower eviction of truly failed consumers.
If processing time per poll batch is legitimately long (e.g., batch calls to an external API), set max.poll.interval.ms to the maximum acceptable processing time. Default is 5 minutes; if processing takes 8 minutes per batch, the consumer will be evicted. Increasing this value prevents false evictions but delays detection of truly stuck consumers.
Backpressure prevents slow consumers from falling further behind by signaling producers to pause, giving the consumer time to drain its backlog before new messages arrive.
Configure partition.assignment.strategy = CooperativeStickyAssignor in all consumers. Cooperative rebalancing only revokes and reassigns affected partitions instead of stopping all consumers. A single slow consumer's partitions are reassigned without pausing the rest of the group.
Reduce max.poll.records (default 500) to limit the number of messages fetched per poll. Smaller batches mean shorter processing windows per poll cycle, reducing the risk of exceeding max.poll.interval.ms due to a large batch of slow messages.
Affected Systems
Workloads
Blast radius analysis is derived from structured topology and failure mode knowledge. It models structural propagation patterns, not measured production behavior. Actual incident scope depends on runtime conditions, traffic, and recovery actions in place at the time of failure.