Static Membership and Reducing Rebalances

A rolling deployment replaces processes, but it often does not change the application’s intended capacity or subscriptions. Treating every replacement as a different consumer can move partitions away from an instance just before its replacement becomes ready to take them back.

Static membership gives a consumer an identity that survives process restarts. Kafka can retain that member’s place in the group through a temporary interruption, reducing assignment changes that do not help the application.

In this chapter, we’ll examine how that identity works, what happens during a short restart or a permanent failure, and how to deploy it without leaving partitions waiting unnecessarily. We’ll use a KRaft-based Kafka 4.3 cluster and the Apache Kafka Java consumer with automatic assignment through subscribe(). Both the classic and consumer group protocols support static membership, though some recovery behavior differs.