Могут ли топики в Kafka включать сообщения различных типов

Могут ли топики в Kafka включать сообщения различных типов

Короткий ответ

Технически ДА, Kafka не ограничивает тип сообщений. Но архитектурно это плохая идея. Давайте разберемся почему.

Технический аспект: Kafka не имеет типизации

Кaffka на фундаментальном уровне:
- Topic = stream of bytes
- Partition = sequence of records
- Record = key (bytes) + value (bytes) + headers (bytes)

Кaffka не знает и не заботит:
- Какой формат у этих bytes (JSON, Protobuf, Avro)
- Какие типы данных содержатся
- Согласованность типов между сообщениями

// На level API это выглядит так:
public class ProducerExample {
    public static void main(String[] args) {
        Producer<String, String> producer = new KafkaProducer<>(
            new StringSerializer(),
            new StringSerializer()
        );
        
        // Kafka позволит отправить любой String
        // (формально он не проверяет содержимое)
        producer.send(new ProducerRecord<>("mixed-topic", 
            "order-placed",
            "{\"orderId\": 123}"));
        
        producer.send(new ProducerRecord<>("mixed-topic",
            "payment-processed", 
            "{\"paymentId\": 456}"));
        
        producer.send(new ProducerRecord<>("mixed-topic",
            "user-registered",
            "{\"userId\": 789}"));
        
        // Все три разных типа событий в одном topic!
    }
}

Почему это плохая архитектура

Проблема 1: Сложная десериализация у потребителя

// ❌ Сложно: потребитель должен парсить разные типы
public class MixedEventConsumer {
    @KafkaListener(topics = "mixed-topic")
    public void consume(String message) throws JsonProcessingException {
        JsonNode node = objectMapper.readTree(message);
        String eventType = node.get("eventType").asText();
        
        switch (eventType) {
            case "order-placed":
                handleOrderPlaced(objectMapper.treeToValue(node, OrderPlacedEvent.class));
                break;
            case "payment-processed":
                handlePaymentProcessed(objectMapper.treeToValue(node, PaymentProcessedEvent.class));
                break;
            case "user-registered":
                handleUserRegistered(objectMapper.treeToValue(node, UserRegisteredEvent.class));
                break;
            default:
                log.warn("Unknown event type: {}", eventType);
        }
    }
}

// Проблемы:
// - Потребитель должен знать ВСЕ возможные типы
// - Если добавим новый тип события, нужно менять код
// - Ошибки парсинга - сложно отладить
// - Производительность: парсим дважды

Проблема 2: Масштабирование потребителей

Сценарий: у нас есть разные сервисы которые слушают события:
- OrderService слушает только "order-placed"
- PaymentService слушает только "payment-processed"
- UserService слушает только "user-registered"

❌ Если все подписаны на "mixed-topic":
- OrderService получает и payment events (ненужные)
- Вызывает лишнее сообщение десериализации
- Consumer group offset смещается медленнее
- Сложнее скейлить отдельные consumer groups

✓ Если каждый слушает свой topic:
- Каждый сервис получает ТОЛЬКО нужные события
- Каждый может скейлиться независимо
- Нет лишнего трафика

Проблема 3: Мониторинг и отладка

// ❌ Как мониторить "mixed-topic"?
Metrics:
- messages per second - какого типа?
- error rate - какие события падают?
- latency - разные события имеют разную latency
- consumer lag - lag по какому типу события?

✓ Если разные topics:
- Четкие метрики per event type
- Легко заметить проблемы
- Легко выставить алерты

Проблема 4: Версионирование и evolution

// ❌ Сложное: разные версии разных типов
@KafkaListener(topics = "mixed-topic")
public void consume(String message) {
    // v1: {"orderId": 123, "amount": 100}
    // v2: {"orderId": 123, "amount": 100, "currency": "USD"}
    // v3: {"orderId": 123, "amount": 100, "currency": "USD", "items": [...]}
    
    // Как разобраться какая версия?
    // Как миграцию делать?
}

// ✓ Четко: каждый topic имеет свою версию
topic "orders.v1" -> OrderEvent_v1
topic "orders.v2" -> OrderEvent_v2 (новый consumer подгружает оба)

Правильный подход: одно событие = один topic

// ✓ Правильная архитектура

// 1. Определяем события
public record OrderPlacedEvent(
    String orderId,
    BigDecimal amount,
    Instant timestamp
) {}

public record PaymentProcessedEvent(
    String paymentId,
    String orderId,
    BigDecimal amount,
    Instant timestamp
) {}

public record UserRegisteredEvent(
    String userId,
    String email,
    Instant timestamp
) {}

// 2. Каждое событие в свой topic
@Configuration
public class KafkaTopicConfig {
    @Bean
    public NewTopic orderPlacedTopic() {
        return new NewTopic("order-placed", 3, (short) 1);
    }
    
    @Bean
    public NewTopic paymentProcessedTopic() {
        return new NewTopic("payment-processed", 3, (short) 1);
    }
    
    @Bean
    public NewTopic userRegisteredTopic() {
        return new NewTopic("user-registered", 3, (short) 1);
    }
}

// 3. Простые потребители
@Component
public class OrderEventConsumer {
    @KafkaListener(topics = "order-placed")
    public void handleOrderPlaced(OrderPlacedEvent event) {
        // ТОЛЬКО order placed события
        // Никакой условной логики
        orderService.process(event);
    }
}

@Component
public class PaymentEventConsumer {
    @KafkaListener(topics = "payment-processed")
    public void handlePaymentProcessed(PaymentProcessedEvent event) {
        // ТОЛЬКО payment processed события
        paymentService.process(event);
    }
}

Исключение: Event streams где один тип события

Есть ситуации где один topic может содержать разные "подтипы" одного события:

// ✓ Это нормально: разные состояния одного типа события
public class OrderEvent {
    public enum Status { PLACED, CONFIRMED, SHIPPED, DELIVERED }
    
    private String orderId;
    private Status status;  // один topic: orders
    private OrderDetails details;
}

// Слушатель:
@KafkaListener(topics = "orders")
public void handleOrderEvent(OrderEvent event) {
    switch (event.getStatus()) {
        case PLACED: handlePlaced(event); break;
        case CONFIRMED: handleConfirmed(event); break;
        case SHIPPED: handleShipped(event); break;
        case DELIVERED: handleDelivered(event); break;
    }
}

// Это нормально потому что:
// - Все это ОДИН тип события
// - Потребитель должен обрабатывать все состояния
// - Семантически это логично

Best Practice: Schema Registry

Для типизации используй Confluent Schema Registry или похожее:

// С Schema Registry типы контролируются
@Configuration
public class KafkaProducerConfig {
    @Bean
    public ProducerFactory<String, OrderPlacedEvent> producerFactory() {
        Map<String, Object> config = new HashMap<>();
        config.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
        config.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, 
                   KafkaAvroSerializer.class);  // Avro с schema validation
        
        return new DefaultProducerFactory<>(config);
    }
    
    @Bean
    public KafkaTemplate<String, OrderPlacedEvent> kafkaTemplate() {
        return new KafkaTemplate<>(producerFactory());
    }
}

// Schema Registry гарантирует:
// - Типизация сообщений
// - Backward compatibility
// - Schema evolution control
// - Topic не может содержать разные типы

Когда все же использовать mixed topics

Редкие случаи где это имеет смысл:

// 1. Generic event log (отладка/audit)
topic "audit-log" = [ANY_EVENT] - может содержать всё
// Причина: это не бизнес-logic, это отладка

// 2. High-throughput generic stream
topic "metrics" = [any metric]
// Причина: metrics collector принимает всё что угодно

// 3. CDC (Change Data Capture) из одной таблицы
topic "customers-cdc" = [INSERT, UPDATE, DELETE events]
// Причина: всё из одного источника, семантически связано

Итоговая рекомендация

Вопрос: Могут ли топики содержать разные типы?
Ответ: Технически ДА, архитектурно - НЕЙТ

Лучшая практика:
✓ Один topic = один тип события
✓ Различные события -> разные topics
✓ Используй Schema Registry для типизации
✓ Потребители просто: нет условной логики
✓ Масштабирование независимо
✓ Мониторинг и отладка просто