---
title: "Kafka message keys: how a key picks the partition"
description: "The same key always hashes to the same partition, which keeps per-key order. Keyless records use the sticky partitioner and spread over 3 Kafka partitions."
url: https://monedula.dev/kafka-simulator/scenarios/keys-and-partitioning/
---

# Kafka message keys: how a key picks the partition

Scenario 00.1.3 · Keys and partitioning. Anatomy · Beginner · about 2 min · Apache Kafka 4.3.

A record’s key decides its partition: same key → same partition (ordering), different keys spread, no key → the sticky partitioner spreads them over time.

Run it: https://monedula.dev/kafka-simulator/playground/?scenario=00.1.3

## What you start with

The record key determines its partition: Kafka hashes the key and maps it to a partition, so identical keys always land together while different keys spread out. With NO key there is nothing to hash, so the default (sticky) partitioner keeps keyless records on one partition for a while, then moves on - they still fan out across partitions over time. Watch keyed records pin by key, then watch keyless records spread (the simulator switches partition per batch so the spread is visible).

## Step by step

1. **Empty topic · 3 partitions** (t+0.000s): A 3-partition topic. The producer uses the default partitioner: with a key, partition = hash(key) mod partitionCount; with no key, the sticky partitioner picks a partition per batch. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=00.1.3&t=0)
2. **Different keys spread across partitions** (t+1.050s): Keys A, C, F hash to different partitions, so the three keyed records spread out - one per partition at offset 0. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=00.1.3&t=1)
3. **Same key → same partition** (t+1.450s): A second record with key A lands in the very same partition as the first A, now at offset 1. The same key always maps to the same partition - that is what guarantees per-key ordering and co-partitioning. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=00.1.3&t=2)
4. **No key → a partition is chosen for the batch** (t+1.850s): Now a record with NO key. There is nothing to hash, so the default (sticky) partitioner simply picks a partition for the batch - this keyless record lands on partition 0. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=00.1.3&t=3)
5. **Keyless records spread across partitions** (t+2.350s): Two more keyless records follow, each its own batch. The simulator moves the sticky partition as each batch closes, so the three keyless records spread across p0, p1, p2. Real Kafka 4.x stays on one partition until batch.size bytes (16 KB) have been sent, then switches to a random, load-weighted partition. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=00.1.3&t=4)

## The takeaway

Use a key when you need per-key ordering - every record for that key shares one partition. Leave the key empty for an even spread: the modern default is the sticky partitioner (it stays on one partition for about batch.size bytes before switching, rather than the older strict per-record round-robin), but either way keyless records distribute across all partitions over time.

## Configs in this scenario

- [`batch.size`](https://kafka.apache.org/43/configuration/producer-configs/#producerconfigs_batch.size): The most bytes the producer puts in one batch for a partition (default 16384); a batch goes out when it is full or when linger.ms runs out, whichever comes first. [How batch.size works](https://monedula.dev/kafka-simulator/configs/batch-size/)

## Further reading

- [Apache Kafka documentation](https://kafka.apache.org/43/getting-started/introduction/)