...

• Class: ReplicationConfigs
• Name: replica.placer.class.name
• Type: string
• Default: StripedReplicaPlacer
• Valid Values: non-empty string
• Document: The fully qualified class name of the ReplicaPlacer implementation. This class is used by the broker to determine the placement of replicas when topics or partitions are created. This configuration is not intended for external users and should only be used in the following scenarios: internal testing environments, experimental feature development, performance evaluation or benchmarking. Custom implementations must be lightweight and efficient to avoid negatively impacting controller performance and overall cluster stability.

...

    public static final String REPLICA_PLACER_CLASS_NAME = "replica.placer.class.name";
    public static final String REPLICA_PLACER_CLASS_NAME_DEFAULT = StripedReplicaPlacer.class.getName();     
	public static final String REPLICA_PLACER_CLASS_NAME_DOC = "The fully qualified class name of the ReplicaPlacer implementation. " +
            "This class is used by the broker to determine the placement of replicas when topics or partitions are created. " +
            "This configuration is not intended for external users and should only be used in the following scenarios: " +
            "internal testing environments, experimental feature development, performance evaluation or benchmarking. \n " +
            "Custom implementations must be lightweight and efficient to avoid negatively impacting controller performance " +
            "and overall cluster stability.";

...

Add new test for new internal config internal.replica.placer.class.name

Rejected Alternatives

KIP-660: Pluggable ReplicaPlacer, but the proposal was ultimately rejected due to the following concerns:

• Implementing an intelligent placement strategy may require access to the full cluster state, which could be prohibitively expensive in large deployments.

• Such strategies could become overly complex and harder to maintain.

• Slow or inefficient placement logic could block the controller thread, negatively impacting Kafka's overall stability.

Using Admin API for Post-Creation Reassignment

Users could create topics with default placement and then use kafka-reassign-partitions or Admin API to reassign partitions, but rejected due to the following concerns:

• Requires additional operational overhead and monitoring
• Difficult to integrate with auto-topic creation scenarios

Specifying Assignment During Topic Creation 

Users could use Admin API's CreateTopicsRequest with explicit ReplicaAssignment when creating topics, but rejected due to the following concerns:

• Pushes complexity to client applications
• Leads to inconsistent placement strategies across different clients  
• Not suitable for internal testing scenarios where broker-level control is required