Partition key and routing in Kafka - Step-by-Step Execution

Process Flow - Partition key and routing

Message Created

↓

Check for Partition Key?

No→Use Round-Robin Partitioning

Yes↓

Hash Partition Key

↓

Calculate Partition Number

↓

Send Message to Partition

Kafka decides which partition a message goes to by checking if it has a key. If yes, it hashes the key to pick a partition. If no key, it uses round-robin.

Execution Sample

Kafka

producer.send(topic, key=b'user1', value=b'msg1')
producer.send(topic, key=b'user2', value=b'msg2')
producer.send(topic, value=b'msg3')

Send three messages: two with keys (user1, user2) and one without key to a Kafka topic.

Process Table

Step	Message	Has Key?	Key Value	Partition Calculation	Partition Chosen	Action
1	msg1	Yes	user1	hash('user1') % 3 = 1	Partition 1	Send to Partition 1
2	msg2	Yes	user2	hash('user2') % 3 = 0	Partition 0	Send to Partition 0
3	msg3	No	None	Round-Robin next partition = 2	Partition 2	Send to Partition 2
4	End	-	-	-	-	All messages routed

💡 All messages processed and assigned to partitions based on key or round-robin

Status Tracker

Variable	Start	After 1	After 2	After 3	Final
partition	None	1	0	2	2
key	None	user1	user2	None	None
round_robin_counter	0	0	0	2	2

Key Moments - 2 Insights

Why does the message without a key go to Partition 2?

Because it has no key, Kafka uses round-robin to assign partitions. The round-robin counter was at 2 for this message (see execution_table row 3).

How is the partition number calculated for messages with keys?

Kafka hashes the key string and then takes the remainder when divided by the number of partitions (3 here). This is shown in execution_table rows 1 and 2.

Visual Quiz - 3 Questions

Look at the execution table, what partition does the message with key 'user2' go to?

A Partition 1

B Partition 2

C Partition 0

D Partition 3

💡 Hint

Check execution_table row 2 under 'Partition Chosen'

At which step does Kafka use round-robin to assign a partition?

A Step 3

B Step 2

C Step 1

D Step 4

💡 Hint

Look for 'Has Key?' = No in execution_table

If the topic had 4 partitions instead of 3, how would the partition for 'user1' change?

A It would still be Partition 1

B It would be hash('user1') % 4, possibly different

C It would use round-robin

D It would always be Partition 0

💡 Hint

Partition depends on hash(key) modulo number of partitions (see execution_table rows 1 and 2)

Concept Snapshot

Kafka uses a partition key to decide where to send messages.
If a key exists, Kafka hashes it and picks a partition by modulo operation.
If no key, Kafka uses round-robin to spread messages evenly.
This ensures messages with the same key go to the same partition.
Partitioning helps Kafka scale and keep message order per key.

Full Transcript

This visual shows how Kafka routes messages to partitions. When a message is created, Kafka checks if it has a key. If yes, it hashes the key and calculates the partition number by taking the hash modulo the number of partitions. If no key is present, Kafka uses round-robin to assign the next partition in order. The execution table traces three messages: two with keys 'user1' and 'user2' and one without a key. The first message goes to partition 1, the second to partition 0, and the third uses round-robin to go to partition 2. Variables like partition number, key, and round-robin counter update step by step. Key moments clarify why messages without keys use round-robin and how partition numbers are calculated. The quiz tests understanding of partition assignment and effects of changing partition count. The snapshot summarizes the key rules of Kafka partitioning for quick review.

Practice

1. What is the main purpose of using a partition key in Kafka?

easy

A. To increase the message size limit

B. To encrypt the message content

C. To ensure related messages go to the same partition

D. To compress the message before sending

Solution

1. Step 1: Understand partition key role

   The partition key is used to decide which partition a message goes to in Kafka.

2. Step 2: Connect key to message ordering

   Using the same key ensures related messages stay in the same partition, preserving order.

3. Final Answer:

   To ensure related messages go to the same partition -> Option C

4. Quick Check:

   Partition key controls message placement = D [OK]

Hint: Partition key groups related messages together [OK]

Common Mistakes:

• Thinking partition key encrypts messages
• Confusing partition key with compression
• Believing partition key increases message size

2. Which of the following is the correct way to specify a partition key when producing a Kafka message in Java?

easy

A. producer.send(new ProducerRecord<>(topic, value));

B. producer.send(new ProducerRecord<>(value, key));

C. producer.send(new ProducerRecord<>(key, topic, value));

D. producer.send(new ProducerRecord<>(topic, key, value));

Solution

1. Step 1: Recall ProducerRecord constructor

   The correct constructor order is (topic, key, value) to specify partition key.

2. Step 2: Match options to constructor

   producer.send(new ProducerRecord<>(topic, key, value)); matches this order exactly, others mix parameters incorrectly.

3. Final Answer:

   producer.send(new ProducerRecord<>(topic, key, value)); -> Option D

4. Quick Check:

   Topic, key, value order = B [OK]

Hint: Remember ProducerRecord(topic, key, value) order [OK]

Common Mistakes:

• Swapping key and value positions
• Omitting the key parameter
• Placing key before topic incorrectly

3. Given a Kafka topic with 3 partitions, what will happen if you send messages with the same partition key "user123" repeatedly?

medium

A. All messages will go to the same partition

B. Messages will be evenly distributed across all partitions

C. Messages will be sent to partition 0 only

D. Messages will be randomly assigned to any partition

Solution

1. Step 1: Understand partition key hashing

   Kafka hashes the partition key to decide the partition number.

2. Step 2: Same key means same hash and partition

   Repeated messages with "user123" key will always hash to the same partition.

3. Final Answer:

   All messages will go to the same partition -> Option A

4. Quick Check:

   Same key -> same partition = C [OK]

Hint: Same key always hashes to same partition [OK]

Common Mistakes:

• Assuming keys distribute evenly without hashing
• Thinking messages go to partition 0 by default
• Believing messages are randomly assigned despite keys

4. You wrote this code to send messages with keys but all messages end up in different partitions. What is the likely mistake?

producer.send(new ProducerRecord<>(topic, null, value));

medium

A. The topic name is missing

B. The key is null, so messages are distributed randomly

C. The value is null, causing errors

D. ProducerRecord constructor is used incorrectly

Solution

1. Step 1: Check the key parameter

   The key is set to null, so Kafka cannot use it for partitioning.

2. Step 2: Understand default partitioning behavior

   Without a key, Kafka distributes messages randomly across partitions.

3. Final Answer:

   The key is null, so messages are distributed randomly -> Option B

4. Quick Check:

   Null key -> random partitions = A [OK]

Hint: Null key means random partition assignment [OK]

Common Mistakes:

• Assuming null key sends to partition 0
• Confusing missing topic with null key
• Thinking null value causes partitioning issues

5. You want to ensure that messages related to the same customer ID always go to the same partition, but your customer IDs sometimes are null or empty strings. How should you handle partition keys to maintain message order for valid IDs and avoid errors?

hard

A. Use the customer ID as key only if it is non-empty; otherwise, assign a default fixed key

B. Always send messages with null keys to let Kafka distribute randomly

C. Convert null or empty IDs to random UUIDs as keys

D. Ignore keys and rely on Kafka's default partitioning

Solution

1. Step 1: Identify the problem with null or empty keys

   Null or empty keys cause Kafka to distribute messages randomly, breaking order.

2. Step 2: Use a default fixed key for missing IDs

   Assigning a fixed key for missing IDs groups those messages in one partition, preserving order for them.

3. Step 3: Keep valid customer IDs as keys

   Valid IDs remain keys to ensure their messages go to the same partition.

4. Final Answer:

   Use the customer ID as key only if it is non-empty; otherwise, assign a default fixed key -> Option A

5. Quick Check:

   Non-empty key or default fixed key = A [OK]

Hint: Use default key for missing IDs to keep order [OK]

Common Mistakes:

• Sending null keys causing random partitioning
• Using random UUIDs breaking message grouping
• Ignoring keys and losing message order