How does Quarkus handle reactive messaging with Kafka?

Quarkus integrates Kafka through the SmallRye Reactive Messaging extension, which implements the MicroProfile Reactive Messaging specification and lets a method be wired to a Kafka topic declaratively, using annotations rather than manually managing a Kafka consumer/producer client.

@Incoming("orders-in")
@Outgoing("orders-processed")
public Multi<OrderEvent> process(Multi<OrderEvent> orders) {
    return orders.map(this::enrich);
}

@Incoming subscribes a method to messages arriving on a named channel, @Outgoing publishes a method's return value to another named channel, and the actual mapping from those logical channel names to real Kafka topics, brokers, and serializers is handled through configuration rather than code — keeping the business logic decoupled from Kafka-specific wiring details.

Because the underlying engine is reactive, backpressure is handled automatically: if downstream processing can't keep up, the reactive streams implementation slows consumption from Kafka rather than letting messages pile up uncontrolled in application memory, which is a meaningful advantage over naively polling a Kafka consumer in a tight loop with no flow control.