Introduction

If you want a Spring Integration Kafka consumer to read from a specific partition, you should use explicit partition assignment instead of normal topic subscription. That tells the container exactly which partition to consume and avoids the usual group-based partition assignment process.

Subscription vs Explicit Partition Assignment

Kafka consumers normally subscribe to a topic and let the consumer group coordinator assign partitions dynamically. That is the right default for scalable consumer groups.

But some use cases need direct control:

• replaying one partition for debugging
• processing a partition with dedicated business logic
• wiring a fixed partition into a specialized integration flow

In those cases, do not rely on plain topic subscription. Create container properties that explicitly identify the partition.

Spring Integration Pattern

In Spring Integration Kafka, the usual flow is:

1. create a listener container
2. wrap it in a KafkaMessageDrivenChannelAdapter
3. route messages into an integration channel

When you need a specific partition, build the container with TopicPartitionOffset.

1import org.springframework.context.annotation.Bean;
2import org.springframework.context.annotation.Configuration;
3import org.springframework.integration.channel.DirectChannel;
4import org.springframework.integration.kafka.inbound.KafkaMessageDrivenChannelAdapter;
5import org.springframework.kafka.core.ConsumerFactory;
6import org.springframework.kafka.listener.ContainerProperties;
7import org.springframework.kafka.listener.KafkaMessageListenerContainer;
8import org.springframework.kafka.support.TopicPartitionOffset;
9import org.springframework.messaging.MessageChannel;
10
11@Configuration
12public class KafkaPartitionConfig {
13
14    @Bean
15    public KafkaMessageListenerContainer<String, String> partitionContainer(
16            ConsumerFactory<String, String> consumerFactory) {
17
18        TopicPartitionOffset topicPartition =
19                new TopicPartitionOffset("orders", 2);
20
21        ContainerProperties properties = new ContainerProperties(topicPartition);
22        properties.setGroupId("orders-fixed-partition-group");
23
24        return new KafkaMessageListenerContainer<>(consumerFactory, properties);
25    }
26
27    @Bean
28    public KafkaMessageDrivenChannelAdapter<String, String> kafkaAdapter(
29            KafkaMessageListenerContainer<String, String> partitionContainer) {
30
31        KafkaMessageDrivenChannelAdapter<String, String> adapter =
32                new KafkaMessageDrivenChannelAdapter<>(partitionContainer);
33        adapter.setOutputChannel(inputChannel());
34        return adapter;
35    }
36
37    @Bean
38    public MessageChannel inputChannel() {
39        return new DirectChannel();
40    }
41}

This configuration pins the consumer to partition 2 of the orders topic.

Starting Offset Behavior

Partition assignment is only part of the story. You also need to think about where consumption starts.

Depending on your needs, you may want:

• the committed offset for that group
• the beginning of the partition
• a specific absolute offset

TopicPartitionOffset supports more explicit offset control when needed. For example, you can assign a particular offset instead of relying on the group’s last commit.

That is useful for replay workflows, but it changes the semantics significantly. A fixed offset is a deliberate operational choice, not something to turn on casually in normal production consumers.

What Changes When You Pin a Partition

Explicit partition assignment gives you precision, but it also gives up some of the conveniences of normal group-based subscription.

With a normal subscription:

• Kafka balances partitions across group members
• scaling out is straightforward
• partition ownership can shift automatically

With fixed partition assignment:

• this consumer targets only the partitions you named
• scaling requires explicit configuration decisions
• rebalancing is no longer doing the partition choice for you

That is why direct partition assignment is best used for special-purpose consumers rather than as a default architecture for every service.

Integrating the Messages Into a Flow

Once the adapter pushes records into a message channel, the rest of the Spring Integration flow can stay normal.

1import org.springframework.context.annotation.Bean;
2import org.springframework.integration.dsl.IntegrationFlow;
3
4@Bean
5public IntegrationFlow ordersFlow() {
6    return IntegrationFlow.from("inputChannel")
7            .handle(message -> System.out.println(message.getPayload()))
8            .get();
9}

This shows the main advantage of Spring Integration here. Partition targeting is handled at the Kafka boundary, while the downstream flow stays focused on message processing.

When to Use @KafkaListener Instead

If you do not specifically need Spring Integration channels and adapters, plain Spring Kafka with @KafkaListener and @TopicPartition may be simpler. But if your application already models message routing through integration flows, the adapter-based approach keeps the design consistent.

So the decision is not only about Kafka. It is also about whether the rest of your application already uses Spring Integration patterns.

Common Pitfalls

The most common pitfall is subscribing to a topic normally and expecting a single partition to stay fixed. Standard topic subscription allows Kafka to assign partitions dynamically.

Another mistake is pinning a partition without thinking about offsets. Partition choice and starting point are related but separate decisions.

A third issue is using explicit partition assignment in places that really want scalable consumer-group behavior. Fixed partitions reduce flexibility.

Finally, some developers mix up Spring Kafka examples with Spring Integration Kafka configuration. The concepts overlap, but the adapter and channel wiring are specific to Spring Integration.

Summary

• To consume from a specific partition in Spring Integration Kafka, use explicit partition assignment.
• Build the container with TopicPartitionOffset instead of plain topic subscription.
• Wrap that container in a KafkaMessageDrivenChannelAdapter to feed the integration flow.
• Think separately about partition selection and offset starting position.
• Use this pattern for deliberate partition control, not as the default for every consumer.