Rebalance Triggers

A rebalance is often the first visible sign of a change elsewhere: a deployment starts another consumer, a slow database keeps a member away from its poll loop, or a new topic enters a pattern subscription. Knowing that the group rebalanced tells you what Kafka did. It does not yet tell you why.

In this chapter, we’ll identify the changes that cause Kafka to reconsider partition ownership, distinguish them from events that only affect record fetching, and trace how one incident can create repeated rebalances.

We’ll use a KRaft-based Kafka 4.3 cluster and the Apache Kafka Java consumer with automatic assignment through subscribe(). Our order-reporting group reads four partitions of orders.placed. Unless stated otherwise, its consumers use dynamic membership, with no group.instance.id configured. The examples apply to both group protocols, with explanations where they differ.