2 topics: 2 listeners or 1 listener?

[midovlvn]

Let's say I have apple and pear topicc, 8 partition each. Apple and Pear schema is different.
Let's say I have 4 CPU.
What is better:

1. @KafkaListener(topics={"apple","pear"}, groupId="fruits", concurrency=4)
2. @KafkaListener(topics="apple", groupId="fruits", concurrency=2) + @KafkaListener(topics="pear", groupId="fruits", concurrency=2)
3. something else

My hypothesis is that Kafka broker contains logic to distribute fruits from different topics over consumers from the same group (fruits). From that perspective pattern @KafkaListener per topic is micro-management distribution, which may cause unwanted under-utilization. Therefore, applications should let broker distribute messages over consumers and focus on processing messages.
On the other hand, Spring Kafka design encourages to have listener per message class, because message class is part of the signature. When each topic has own schema, Spring Kafka encourages to create multiple @KafkaListener's.

Encourage does not mean that the following code is impossible

@KafkaListener(topics={"apple","pear"}, groupId="fruits", concurrency=4)
void eat(Object o) {
  if (o instanceof Apple a) eatApple(a);
  ...

Encourage means that Spring Kafka is designed for homogeneous listeners and use cases for heterogeneous listeners is not documented

[gpando]

https://docs.spring.io/spring-kafka/docs/current/reference/html/#class-level-kafkalistener

[garyrussell]

Please be aware that class level listeners require the payload to be deserialized by the Kafka deserializer since we use the payload type to determine which handler method to call. With method-level listeners, we can infer the type directly from the method signature.