...

• Safety: Quorum checks and leader decisions are based on a membership configuration that is guaranteed to be replicated and agreed upon by a majority.

• Stability: The committed voter set changes only at commit points, avoiding transient or rolled-back configurations.

• Correctness under Reconfiguration: Both during joint consensus transitions and simple add/remove operations, the system preserves Raft’s safety guarantees.

Public Interfaces

Request Schema

Benefit

This mechanism strengthens the Raft membership model by:

• Making committed membership explicit.

• Providing a consistent interface for tooling and client introspection.

• Improving the overall transparency and debuggability of the cluster state.

• Reducing performance overhead by avoiding disk operations, since all required voter state and high watermark data are memory-resident.

Public Interfaces

Request Schema

{
  "apiKey": 55,

{
  "apiKey": 55,
  "type": "request",
  "listeners": ["broker", "controller"],
  "name": "DescribeQuorumRequest",
  // Version 1 adds additional fields in the response. The request is unchanged (KIP-836).
  // Version 2 adds additional fields in the response. The request is unchanged (KIP-853).
+ // Version 3 adds additional fields in the response. The request is unchanged.
+ "validVersions": "0-3",
  "flexibleVersions": "0+",
  "latestVersionUnstable": false,
  "fields": [
    { "name": "Topics", "type": "[]TopicData", "versions": "0+",
      "about": "The topics to describe.", "fields": [
      { "name": "TopicName", "type": "string", "versions": "0+", "entityType": "topicName",
        "about": "The topic name." },
      { "name": "Partitions", "type": "[]PartitionData", "versions": "0+",
        "about": "The partitions to describe.", "fields": [
        { "name": "PartitionIndex", "type": "int32", "versions": "0+",
          "about": "The partition index." }
      ]
      }]
    }
  ]
}

...

The leaderState is extended to reference the KRaftControlRecordStateMachine, from which derives the high watermark. Using this information the committed voter set can be obtained directly from KRaftControlRecordStateMachine. Both the voter set in the KRaftControlRecordStateMachine and the high watermark are maintained entirely in memory. This eliminates disk I/O, there by, minimizing performance impact.

Semantic

The relationship between voters and committed voters is defined as follows:

Scenario

Committed voter present in voters/observers
If a committed voter is also present in the current voters or observers set, its ReplicaState is identical to the corresponding entry in those sets. This ensures that all runtime fields within ReplicaState are available.Committed voter absent from voters or observers 

Committed voter absent from voters or observers
If a committed voter is not found in either voters or observers, certain runtime-specific fields cannot be derived, since the replica is no longer actively participating in log replication. To maintain schema consistency, these fields in its ReplicaState are set to sentinel values:

...

These fields are only meaningful for active replicas in the quorum. For committed voters, they are not strictly required—the sentinel values simply indicate that the data is unavailable or not applicable.

Benefit

This mechanism strengthens the Raft membership model by:

...

Making committed membership explicit.

...

Providing a consistent interface for tooling and client introspection.

...

Improving the overall transparency and debuggability of the cluster state.

...

.

Case Study: Voter Status Scenarios

...