Partition concept in Kafka - Commands & Configuration

Introduction

Kafka partitions split a topic into smaller parts so messages can be stored and processed in parallel. This helps handle more data and keeps the system fast and reliable.

When you want to increase the speed of message processing by spreading load across multiple servers.

When you need to keep the order of messages for a specific key but allow parallel processing for different keys.

When your topic receives more messages than a single server can handle efficiently.

When you want to scale your Kafka cluster by adding more brokers and distributing partitions among them.

When you want to improve fault tolerance by replicating partitions across different servers.

Config File - topic-config.json

topic-config.json

{
  "TopicName": "example-topic",
  "Partitions": 3,
  "ReplicationFactor": 2
}

This JSON file defines a Kafka topic named example-topic with 3 partitions. Each partition allows parallel processing of messages. The ReplicationFactor of 2 means each partition is copied to two brokers for safety.

Commands

This command creates a Kafka topic named example-topic with 3 partitions and a replication factor of 2. Partitions allow parallel processing and replication ensures data safety.

Terminal

kafka-topics.sh --create --topic example-topic --partitions 3 --replication-factor 2 --bootstrap-server localhost:9092

Expected Output

Created topic example-topic.

→

--partitions - Sets the number of partitions for the topic

→

--replication-factor - Sets how many copies of each partition exist

→

--bootstrap-server - Specifies the Kafka server to connect to

This command shows details about the topic, including the number of partitions and their leaders. It helps verify the topic was created correctly.

Terminal

kafka-topics.sh --describe --topic example-topic --bootstrap-server localhost:9092

Expected Output

Topic: example-topic	PartitionCount: 3	ReplicationFactor: 2	Configs: 

	Topic: example-topic	Partition: 0	Leader: 1	Replicas: 1,2	Isr: 1,2

	Topic: example-topic	Partition: 1	Leader: 2	Replicas: 2,3	Isr: 2,3

	Topic: example-topic	Partition: 2	Leader: 3	Replicas: 3,1	Isr: 3,1

→

--describe - Shows detailed information about the topic

→

--topic - Specifies which topic to describe

→

--bootstrap-server - Specifies the Kafka server to connect to

Key Concept

Partitions split a topic so messages can be processed in parallel and scaled across servers.

Common Mistakes

Creating a topic with only one partition when expecting high message volume

One partition limits processing to a single server, causing slow performance and no parallelism.

Create the topic with multiple partitions to allow parallel processing and better scalability.

Setting replication factor higher than the number of brokers

Kafka cannot create more replicas than available brokers, causing topic creation to fail.

Ensure the replication factor is less than or equal to the number of Kafka brokers in the cluster.

Summary

Create Kafka topics with multiple partitions to enable parallel message processing.

Use replication factor to keep copies of partitions for fault tolerance.

Verify topic details with the describe command to check partitions and leaders.

Practice

1.

What is the main purpose of partitions in a Kafka topic?

easy

A. To split the topic into smaller parts for better speed and order

B. To encrypt messages for security

C. To store messages permanently on disk

D. To compress messages to save space

Solution

1. Step 1: Understand the role of partitions in Kafka

   Partitions divide a topic into smaller parts to allow parallel processing and maintain message order within each partition.

2. Step 2: Identify the main benefit of partitions

   Partitions improve speed by enabling parallelism and keep order for messages with the same key.

3. Final Answer:

   To split the topic into smaller parts for better speed and order -> Option A

4. Quick Check:

   Partitions = speed and order [OK]

Hint: Partitions split topics to speed up and keep order [OK]

Common Mistakes:

• Confusing partitions with encryption
• Thinking partitions store messages permanently
• Assuming partitions compress data

2.

Which of the following is the correct way to specify the number of partitions when creating a Kafka topic using the command line?

kafka-topics.sh --create --topic my-topic --bootstrap-server localhost:9092 --partitions ?

easy

A. --num-partitions 3

B. --partition-count 3

C. --partitions 3

D. --partition 3

Solution

1. Step 1: Recall Kafka topic creation syntax

   The correct option to specify partitions is '--partitions' followed by the number.

2. Step 2: Match the correct option

   Among the options, '--partitions 3' is the valid syntax for setting 3 partitions.

3. Final Answer:

   --partitions 3 -> Option C

4. Quick Check:

   Partitions flag = --partitions [OK]

Hint: Use --partitions to set number when creating topic [OK]

Common Mistakes:

• Using --partition-count instead of --partitions
• Using --num-partitions which is invalid
• Using singular --partition flag

3.

Given a Kafka topic with 3 partitions, if messages with keys "key1", "key2", and "key1" are sent in that order, which partition will the second "key1" message go to?

medium

A. Partition 1

B. Same partition as the first "key1" message

C. Partition 0

D. A random partition different from the first "key1" message

Solution

1. Step 1: Understand key-based partitioning

   Kafka uses the message key to decide the partition. Messages with the same key always go to the same partition.

2. Step 2: Apply to the given keys

   Since both messages have key "key1", the second message will go to the same partition as the first "key1" message.

3. Final Answer:

   Same partition as the first "key1" message -> Option B

4. Quick Check:

   Same key = same partition [OK]

Hint: Same keys always go to the same partition [OK]

Common Mistakes:

• Assuming keys distribute randomly each time
• Thinking second message goes to a different partition
• Ignoring key-based partitioning

4.

Consider this Kafka producer code snippet in Java:

ProducerRecord record = new ProducerRecord<>("my-topic", null, "message");
producer.send(record);

What is the issue related to partitioning in this code?

medium

A. The key is null, so messages may be sent to random partitions

B. The topic name is missing

C. The message value is null

D. Producer is not closed after sending

Solution

1. Step 1: Analyze the ProducerRecord parameters

   The key parameter is null, which means Kafka cannot use key-based partitioning.

2. Step 2: Understand partition assignment without a key

   Without a key, Kafka assigns messages to partitions in a round-robin or default way, which can be random.

3. Final Answer:

   The key is null, so messages may be sent to random partitions -> Option A

4. Quick Check:

   Null key = random partition [OK]

Hint: Null key means no fixed partition, messages spread randomly [OK]

Common Mistakes:

• Thinking topic name is missing (it is present)
• Assuming message value is null (it's "message")
• Ignoring partitioning effect of null key

5.

You have a Kafka topic with 4 partitions. You want to ensure that all messages with the same customer ID go to the same partition to keep their order. Which approach should you use?

hard

A. Create 4 separate topics, one per customer

B. Send all messages to partition 0 manually

C. Use a random key for each message

D. Use the customer ID as the message key when producing messages

Solution

1. Step 1: Understand how Kafka assigns partitions

   Kafka uses the message key to decide which partition a message goes to, ensuring order for messages with the same key.

2. Step 2: Apply to customer ID ordering requirement

   Using the customer ID as the key ensures all messages for that customer go to the same partition and keep order.

3. Step 3: Evaluate other options

   Sending all to partition 0 limits scalability; random keys break order; separate topics complicate management.

4. Final Answer:

   Use the customer ID as the message key when producing messages -> Option D

5. Quick Check:

   Key = customer ID for order [OK]

Hint: Use customer ID as key to keep order in one partition [OK]

Common Mistakes:

• Sending all messages to one partition reduces scalability
• Using random keys breaks message order
• Creating multiple topics is unnecessary and complex