Overview
With a key, the producer picks the partition from a murmur2 hash of the serialized key modulo the partition count. Without a key, and without an explicit partition, it sticks to one partition until at least batch.size bytes have been produced to it, then switches: the sticky partitioner, available since Kafka 2.4, which makes larger batches than the round-robin behaviour it replaced. Since KIP-794 the next partition is chosen adaptively by default, favouring partitions on faster brokers. Custom partitioners implement the Partitioner interface, and RoundRobinPartitioner ships with the client. Changing a topic's partition count changes the result of hash % partition count, so existing keys can map to different partitions.
Key configuration
partitioner.class — default null: the built-in logic is used (key hash, otherwise sticky); alternatives are org.apache.kafka.clients.producer.RoundRobinPartitioner or your own Partitioner
partitioner.ignore.keys=false — default; if true, the key is not used to choose the partition
partitioner.adaptive.partitioning.enable=true — default: produce more to partitions hosted on faster brokersProduction tip
Check yourself
Producers write with keys to a topic. You add more partitions. What is the risk?
Sources
- BuiltInPartitioner.java (4.2 source) (opens in a new tab)
- Producer configs (4.2 documentation) (opens in a new tab)
- Partitioner Javadoc (4.2) (opens in a new tab)
- KIP-480: Sticky Partitioner (opens in a new tab)
- Basic Kafka operations (4.2 documentation) (opens in a new tab)
Checked against Kafka 4.2 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.