KafkaConfig Reference
Compose a record and see exactly which partition its key lands on — computed with Kafka's own murmur2 partitioner, no broker required.
In-browser & private
Headers
Partition
—
Where keys land
Key bytes 0
Value bytes 0
Headers 0
Record 0 B
Why the partition matters
Kafka guarantees order within a partition, never across a topic. So "will these two events be processed in order?" is really "do these two keys hash to the same partition?" — and that is the question this page answers without a cluster.
- The number is real. The partition is computed with a port of
Utils.murmur2from Kafka itself, thentoPositive(hash) % partitions, which is precisely what the default partitioner does. It is verified against the Java original. - No key means no guarantee. A record with a null key is not hashed at all — the sticky partitioner batches it wherever is convenient, so two null-key events can be processed out of order even if you send them a millisecond apart.
- Changing the partition count re-shuffles everything. The modulo is over the partition count, so adding partitions sends existing keys somewhere new — and ordering across that change is lost. Try it with the partitions box.
- Skew is visible. The spread chart shows where a set of sample keys land. A tall bar next to empty ones is a hot partition, which is how one consumer ends up doing all the work.