Introduction

Kafka normally chooses a partition for you based on the record key or the configured partitioner. When you need to force records into one exact partition for testing, debugging, or ordered replay, kafka-console-producer can do that directly from the command line.

Why You Might Target One Partition

Kafka preserves ordering only within a single partition, not across an entire topic. That means producing deliberately to partition 2 can be useful when you want to:

• reproduce a bug tied to one partition
• verify consumer lag or rebalancing behavior
• test ordering guarantees
• populate a known partition with sample data

This is mostly an operational or debugging technique. In normal application code, you usually rely on keys rather than hardcoding partition numbers.

The Basic Command

If you want every message from the console session to go to one partition, use the --partition option.

1kafka-console-producer \
2  --bootstrap-server localhost:9092 \
3  --topic orders \
4  --partition 2

After running the command, type lines into standard input and press Enter after each message. Every line you send in that session goes to partition 2 of the orders topic.

This is the simplest answer to the question.

Verify the Partition Exists First

Kafka will not create arbitrary partition numbers for an existing topic. If the topic has partitions 0, 1, and 2, then --partition 2 is valid, but --partition 3 is not.

You can inspect topic metadata first:

1kafka-topics \
2  --bootstrap-server localhost:9092 \
3  --describe \
4  --topic orders

Look for the partition list and leader assignments before producing test data.

Producing Keyed Records Is Different

People often mix up two separate ideas:

• choosing a partition explicitly with --partition
• letting Kafka route by key

If you want key-based routing from the console producer, use parsing properties instead:

1kafka-console-producer \
2  --bootstrap-server localhost:9092 \
3  --topic orders \
4  --property parse.key=true \
5  --property key.separator=:

Then send input like this:

customer-42:first order
customer-42:second order
customer-19:another order

With keyed production, the partition is chosen by the partitioner based on the key. With --partition, you override that and send straight to a specific partition.

A Practical Testing Workflow

A common pattern is:

1. describe the topic
2. choose an existing partition
3. produce a few known test records
4. consume from that partition to confirm delivery

For example:

1kafka-console-producer \
2  --bootstrap-server localhost:9092 \
3  --topic orders \
4  --partition 1

Then in another terminal:

1kafka-console-consumer \
2  --bootstrap-server localhost:9092 \
3  --topic orders \
4  --partition 1 \
5  --from-beginning

This is an easy way to prove that your messages landed exactly where you expected.

What Happens in Real Producers

In application code, you usually do not hardcode partition numbers unless there is a strong operational reason. More commonly, the producer either:

• sends records without a key and lets Kafka distribute them
• sends records with a key so related data stays together

A Java producer example that explicitly targets a partition looks like this:

1import org.apache.kafka.clients.producer.KafkaProducer;
2import org.apache.kafka.clients.producer.ProducerRecord;
3import java.util.Properties;
4
5Properties props = new Properties();
6props.put("bootstrap.servers", "localhost:9092");
7props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
8props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
9
10KafkaProducer<String, String> producer = new KafkaProducer<>(props);
11producer.send(new ProducerRecord<>("orders", 2, null, "manual-partition-message"));
12producer.close();

That code mirrors what the console producer is doing for manual testing.

Common Pitfalls

A frequent mistake is trying to use a partition number that does not exist in the topic. Always describe the topic first if you are not sure.

Another issue is confusing keys with partitions. Keys influence partition selection under the normal partitioner, but --partition bypasses that logic for the records you send in that session.

People also test with --partition and then assume application producers behave the same way by default. They do not unless the code explicitly sets the partition or the key hashing happens to route records there.

Finally, make sure you are using --bootstrap-server with a reachable broker. If the command cannot connect, partition selection is not the problem.

Summary

• Use kafka-console-producer --partition N to send messages to one chosen partition.
• Verify the topic's partition count before producing.
• Do not confuse explicit partition targeting with key-based routing.
• Use a matching consumer to confirm where your test messages landed.
• Hardcoded partitions are most useful for debugging and controlled testing, not as a general production default.