The New Consumer Rebalance Protocol (KIP-848)

Overview

In the classic protocol every join, leave or failure sends the whole group through a synchronization barrier, and even cooperative rebalancing depends on that barrier. KIP-848 removes it. The group coordinator on the broker computes a target assignment with a server-side assignor, and each member moves toward it through its heartbeats, so a member whose assignment does not change should not be affected at all. The protocol is generally available in Kafka 4.0. The broker side is enabled when the 4.0 upgrade is finalized, and each consumer opts in with group.protocol=consumer. Members are fenced by epochs, and static membership still works. Two things to check first: client-side assignors are not supported, and the 4.0 documentation says rack-aware assignment is not fully supported. A classic group can be converted online with a rolling restart, provided its assignor does not embed custom metadata. Since 4.3 a consumer that starts on the classic protocol logs a recommendation to move, because the classic protocol is expected to be deprecated in a future release.

Analogy

Key configuration

What changes for clientsproperties

# Client opt-in (the default is classic)
group.protocol=consumer

# Not supported by the client with the new protocol, and where each one moved
partition.assignment.strategy -> broker: group.consumer.assignors              (default uniform,range)
session.timeout.ms            -> broker: group.consumer.session.timeout.ms     (default 45000)
heartbeat.interval.ms         -> broker: group.consumer.heartbeat.interval.ms  (default 5000)

# Optional: choose a server-side assignor for this consumer
group.remote.assignor=range

# Classic default, for comparison (4.2 documentation)
partition.assignment.strategy=RangeAssignor,CooperativeStickyAssignor

Production tip

Check yourself

What happens to a consumer whose partitions do not change when another member joins a group on the KIP-848 protocol?

Sources

Checked against Kafka 4.3 documentation on Oct 2026. Draft: not yet reviewed by a Kafka specialist. Releases move on, so confirm against the current documentation before you act on a number.