Partition key and routing in Kafka - Commands & Configuration

Introduction

When sending messages to Kafka, you want related messages to go to the same place so they can be processed in order. Partition keys help decide which partition a message goes to, making sure messages with the same key stay together.

When you want all messages about the same user to be processed in order.

When you need to balance message load evenly across servers.

When you want to group messages by a category like product ID or region.

When you want to make sure related events are handled by the same consumer.

When you want to improve performance by controlling message distribution.

Config File - producer.properties

producer.properties

bootstrap.servers=localhost:9092
key.serializer=org.apache.kafka.common.serialization.StringSerializer
value.serializer=org.apache.kafka.common.serialization.StringSerializer

This file configures the Kafka producer client.

bootstrap.servers tells the producer where the Kafka servers are.

key.serializer and value.serializer tell Kafka how to turn your keys and messages into bytes.

Commands

This command starts a Kafka producer that reads messages from your keyboard. It uses the text before ':' as the partition key to decide where to send each message.

Terminal

kafka-console-producer --broker-list localhost:9092 --topic example-topic --property parse.key=true --property key.separator=:

Expected Output

No output (command runs silently)

→

--property parse.key=true - Enable parsing of keys from input lines

→

--property key.separator=: - Set ':' as the separator between key and message

This sends a single message with key 'user1' and value 'Hello Kafka' to the topic. The key ensures this message goes to the same partition as other 'user1' messages.

Terminal

echo "user1:Hello Kafka" | kafka-console-producer --broker-list localhost:9092 --topic example-topic --property parse.key=true --property key.separator=:

Expected Output

No output (command runs silently)

→

--property parse.key=true - Enable parsing of keys from input lines

→

--property key.separator=: - Set ':' as the separator between key and message

This command reads messages from the topic from the start and shows both the key and the message, so you can see how keys are used for routing.

Terminal

kafka-console-consumer --bootstrap-server localhost:9092 --topic example-topic --from-beginning --property print.key=true --property key.separator=:

Expected Output

user1:Hello Kafka

→

--property print.key=true - Show the key along with the message

→

--property key.separator=: - Set ':' as the separator between key and message

Key Concept

Partition keys decide which partition a message goes to, keeping related messages together for ordered processing.

Common Mistakes

Not setting parse.key=true when sending messages with keys

Kafka treats the whole message as value and ignores the key, so messages won't be routed as expected.

Always use --property parse.key=true and set the key separator when sending keyed messages.

Using different key separators between producer and consumer

The consumer won't correctly display keys if the separator doesn't match the producer's setting.

Use the same key.separator value for both producer and consumer commands.

Sending messages without keys when order matters for a group

Messages may go to different partitions and be processed out of order.

Always provide a partition key for messages that need ordered processing together.

Summary

Use partition keys to control which partition a Kafka message goes to.

Set --property parse.key=true and key.separator when producing messages with keys.

Use --property print.key=true and matching key.separator when consuming to see keys.

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