Kafka for Beginners: Topics, Partitions, Murmur2, ZooKeeper, KRaft, Replication and Acknowledgements — Part2
Continuing from our previous part, where we discussed basics of Kafka and it’s component. Now it’s time to dive into partitioning and how it works in Kafka.
1. Now Let’s Return to Partitions
Suppose we have:
Topic: ordersP0
P1
P2A producer sends:
Key = customer-101
Value = Order-5001The producer needs to decide:
Which partition should receive this record?
This is where the partitioner comes in.
2. How Does Kafka Select a Partition?
The Kafka producer has a component called the partitioner.
The partitioner determines which partition should receive a record.
There are two important scenarios:
- The record has a key.
- The record does not have a key.
Let’s first look at a keyed record.
3. Partition Selection When a Key Is Present
Suppose our topic has three partitions:
Topic: ordersP0
P1
P2The producer sends:
Key = customer-101
Value = Order-5001Conceptually:
customer-101
|
v
Hashing
|
v
Hash value
|
v
Partitioner
|
v
PartitionA simplified view is:
partition = hash(key) % number_of_partitionsThe actual partition selection is performed by the configured producer partitioner.
4. What is Murmur2?
Murmur2 is a hashing algorithm.
In the traditional/default Kafka producer behavior for keyed records, the key is passed through a Murmur2 hash, and that hash participates in selecting the partition.
Conceptually:
Record Key
|
v
Murmur2
|
v
Hash Value
|
v
Partitioner
|
v
PartitionFor example:
customer-101
|
v
Murmur2
|
v
Hash value
|
v
Partition 1It is important to distinguish:
Murmur2
=
Hashing algorithmPartitioner
=
Component responsible for partition selectionSo the overall view is:
Key
|
v
Murmur2
|
v
Hash
|
v
Partitioner
|
v
Partition5. Same Key Normally Goes to the Same Partition
Suppose we send:
customer-101 → Order A
customer-101 → Order B
customer-101 → Order CThe same key goes through the same partitioning logic.
Therefore, under unchanged partitioning conditions:
Partition 1Order A
Order B
Order CThis is one of the most important reasons to use a Kafka key.
Get Ankur Rastogi’s stories in your inbox
Join Medium for free to get updates from this writer.
It allows records for the same entity to remain ordered within a partition.
6. Different Keys Can Go to Different Partitions
Suppose:
customer-101
customer-102
customer-103The partitioner processes each key.
Conceptually:
customer-101 → P0
customer-102 → P2
customer-103 → P1So:
Partition 0
-----------
customer-101Partition 1
-----------
customer-103Partition 2
-----------
customer-102This allows different keys to be processed in parallel.
7. What Happens When There Is No Key?
Suppose:
Key = nullThere is no key to hash.
Modern Kafka producer clients use sticky partitioning behavior for records without keys.
The producer can send records to a partition as a batch and later switch to another partition.
Conceptually:
Order A → P1
Order B → P1
Order C → P1thenOrder D → P2
Order E → P2Therefore:
Without a key, you should not assume that related records will always go to the same partition.
8. Increasing the Number of Partitions
Suppose we initially have:
P0
P1
P2and:
customer-101 → P1Now we increase the topic to six partitions:
P0
P1
P2
P3
P4
P5The partition calculation is now based on a different number of partitions.
Before:hash(key) % 3 → P1After:hash(key) % 6 → potentially P4Therefore:
Increasing the number of partitions can change the partition assignment of keyed records.
This is important for applications that depend on key-based ordering.
10. Partition vs Replication
Partitioning and replication solve different problems.
Partitioning
Provides:
- Scalability
- Parallelism
- Ordering within a partition
We will cover more on replication in next part .. Thanks for your valuable time.





