Consumer group lag means the group is falling behind the rate at which producers are writing new records, and addressing it starts with identifying whether the bottleneck is parallelism, processing efficiency, or fetch tuning.
Key Points: • Scale out by adding more consumer instances to the group, up to the number of partitions on the topic, so work is processed in parallel. • If the topic doesn't have enough partitions to support more consumers, increase the partition count so additional consumers actually get assigned work. • Profile and optimize the per-record processing logic itself — slow downstream calls (DB writes, external APIs) are a very common root cause of lag. • Tune fetch.min.bytes and fetch.max.wait.ms to control how much data is batched per fetch, trading a little latency for higher throughput. • Check that max.poll.records and max.poll.interval.ms are sized so the consumer can process a batch within the allowed interval without triggering a rebalance.
Example: If a consumer group processing clickstream events falls behind because each record triggers a slow synchronous database write, batching those writes or making them asynchronous often closes the gap faster than simply adding more consumer instances.
Interview Tip: A concise interview answer is:
"I'd first check whether the bottleneck is partition count, processing logic, or fetch configuration — usually I scale out consumers up to the partition count, optimize the hot path in the processing code, and tune fetch.min.bytes and fetch.max.wait.ms, adding partitions only if I've run out of room to parallelize further."