title: Kafka consumer/partition vs thread/partition relationship
body: <p>I am new to Apache Kafka and I am trying to understand the differences between:</p>
  <ol>
  <li>Creating two consumers that belong to the same group id that consume from two partitions of the same topic.</li>
  <li>Creating one consumer with two threads that consume from two partitions of the same topic.</li>
  </ol>
  <p><a href="https://i.stack.imgur.com/zlpIN.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/zlpIN.png" alt="enter image description here" /></a></p>
  <p>In the first approach, what I actually understand is that each consumer will only consume the messages of the partition that is &quot;related&quot; to as the two consumers belong to the same group.</p>
  <p>As I can see in the example of the image below, consumer1 will consume AAAA and BBBB and consumer2 will consume CCCC and DDDD.</p>
  <p><a href="https://i.stack.imgur.com/ijaAH.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/ijaAH.png" alt="enter image description here" /></a></p>
  <p>In the second approach, as I can see in the documentation:</p>
  <blockquote>
  <p><strong>Consumer with many threads:</strong> If processing a record takes a while, a single Consumer can run multiple threads to process records, but it is harder to manage offset for each Thread/Task. If one consumer runs multiple threads, then two messages on the same partitions could be processed by two different threads which make it hard to guarantee record delivery order without complex thread coordination. This setup might be appropriate if processing a single task takes a long time, but try to avoid it.</p>
  </blockquote>
  <p>So in the example below, some different situations could happen:</p>
  <ul>
  <li>Thread1 consumes AAAA and CCCC / Thread2 consumes BBBB and DDDD</li>
  <li>Thread1 consumes AAAA and BBBB / Thread2 consumes CCCC and DDDD</li>
  <li>Thread1 consumes AAAA and DDDD / Thread2 consumes CCCC and BBBB</li>
  <li>Thread1 consumes CCCC and DDDD / Thread2 consumes AAAA and BBBB</li>
  <li>Thread1 consumes BBBB and DDDD / Thread2 consumes AAAA and CCCC</li>
  <li>Thread1 consumes BBBB and CCCC / Thread2 consumes AAAA and DDDD</li>
  </ul>
  <p><a href="https://i.stack.imgur.com/YBqgX.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/YBqgX.png" alt="enter image description here" /></a></p>
  <p>The difference between the two approaches looks trivial. Whereas in the first approach each consumer only consumes the partition assigned to it sequentially, in the second approach, each thread can consume from both partitions, but it could happen that Thread1 consumes AAAA and Thread2 BBBB and the process of BBBB finishes before the process AAAA is finished.</p>
  <p>I have developed a Kafka consumer with springboot. My kafka topic has 5 partitions. Each partition has information that needs to be consumed sequentially. I have decided to create only one consumer with 5 threads instead of creating 5 consumers. Theorically, that doesn´t really make sense, because I need to consume the information of each partition sequentially, and creating threads would break that logic.</p>
  <p>In the Kafka listener I have defined RECEIVED_PARTITION_ID to print from which partition is consuming the data. I have configured log4j to print which is the thread that is running the KafkaListener like: [org.springframework.kafka.KafkaListenerEndpointContainer#0-<strong>thread</strong>-C-1]</p>
  <p><em><strong>The code of KafkaConsumer.java:</strong></em></p>
  <pre><code>@KafkaListener(topics = &quot;${kafka.topic}&quot;, groupId = &quot;${kafka.groupid}&quot;, containerFactory = &quot;kafkaListenerContainerFactory&quot;)    
  public void consumeJson(String mensaje,
              @Header(KafkaHeaders.RECEIVED_PARTITION_ID) String partitionID) throws InterruptedException {
          logger.info(&quot;-&gt; Consumed JSon message&quot;);
          logger.info(&quot;-&gt; Read from partition:&quot; + partitionID);
          logger.info(&quot;-&gt; Consumed JSON Message: [&quot; + mensaje.toString()+&quot;]&quot;);
  }
  </code></pre>
  <p><em><strong>The code of KafkaConfiguration.java:</strong></em></p>
  <pre><code>@Bean
  public ConsumerFactory&lt;String, String&gt; consumerFactory() {
      Map&lt;String, Object&gt; config = new HashMap&lt;&gt;();
  
      config.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapAddress);
      config.put(ConsumerConfig.GROUP_ID_CONFIG, groupid);
      config.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class);
      config.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class);
      config.put(ConsumerConfig.MAX_POLL_RECORDS_CONFIG, maxPoll);
      // Commit manual (para poner AckMode.BATCH), por configuraciÃ³n
      config.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, autoCommit);
  
      return new DefaultKafkaConsumerFactory&lt;&gt;(config);
  }
  
  @Bean
  public KafkaListenerContainerFactory&lt;ConcurrentMessageListenerContainer&lt;String,String&gt;&gt; kafkaListenerContainerFactory(){
      ConcurrentKafkaListenerContainerFactory&lt;String, String&gt; factory = new ConcurrentKafkaListenerContainerFactory&lt;String, String&gt;();
      factory.setConsumerFactory(consumerFactory());
      factory.setConcurrency(5);
      // Commit the offset when the listener returns after processing the record. 
      factory.getContainerProperties().setAckMode(ContainerProperties.AckMode.BATCH);
      return factory;
  }
  </code></pre>
  <p>When I run my springboot application and I see the log, it looks like one thread/partition relationship is done like if one consumer/partition was made. Each thread only consumes data from one partition! Thread0 -&gt; Partition0, Thread1 -&gt; Partition1, Thread2 -&gt; Partition2, Thread3 -&gt; Partition3 , Thread4 -&gt; Partition4. I have checked thwosands of Log rows and it always match.</p>
  <p><strong>Little part of the log:</strong></p>
  <blockquote>
  <p>[org.springframework.kafka.KafkaListenerEndpointContainer#0-<strong>3</strong>-C-1][9980][e.e.s.l.KafkaConsumer:][][]
  Consumed JSon message <strong>Read from partition3</strong></p>
  </blockquote>
  <blockquote>
  <p>[org.springframework.kafka.KafkaListenerEndpointContainer#0-<strong>1</strong>-C-1][9980][e.e.s.l.KafkaConsumer:][][]
  Consumed JSon message <strong>Read from partition1</strong></p>
  </blockquote>
  <blockquote>
  <p>[org.springframework.kafka.KafkaListenerEndpointContainer#0-<strong>0</strong>-C-1][9980][e.e.s.l.KafkaConsumer:][][]
  Consumed JSon message <strong>Read from partition0</strong></p>
  </blockquote>
  <blockquote>
  <p>[org.springframework.kafka.KafkaListenerEndpointContainer#0-<strong>4</strong>-C-1][9980][e.e.s.l.KafkaConsumer:][][]
  Consumed JSon message <strong>Read from partition4</strong></p>
  </blockquote>
  <blockquote>
  <p>[org.springframework.kafka.KafkaListenerEndpointContainer#0-<strong>2</strong>-C-1][9980][e.e.s.l.KafkaConsumer:][][]
  Consumed JSon message <strong>Read from partition2</strong></p>
  </blockquote>
  <blockquote>
  <p>[org.springframework.kafka.KafkaListenerEndpointContainer#0-<strong>1</strong>-C-1][9980][e.e.s.l.KafkaConsumer:][][]
  Consumed JSon message <strong>Read from partition1</strong></p>
  </blockquote>
  <p>This doesn´t make sense to me. As the documentation says:</p>
  <blockquote>
  <p><strong>Consumer with many threads:</strong> If processing a record takes a while, a single Consumer can run multiple threads to process records, but it is harder to manage offset for each Thread/Task. If one consumer runs multiple threads, then two messages on the same partitions could be processed by two different threads which make it hard to guarantee record delivery order without complex thread coordination. This setup might be appropriate if processing a single task takes a long time, but try to avoid it.</p>
  </blockquote>
  <p>Can anyone explain me what is happening?
  Which is the difference between same consumer group 5 consumer/ 5 partition relationship and 1 consumer/ 5 thread relationship?</p>
  <p>For now on it looks to be the same.</p>
  <p>Thank you!</p>