Работали ли вы с Kafka Schema Registry и Schema Registry в Spring Cloud
Что проверяют
Понимаете ли вы, зачем реестру схем место в конвейере Kafka и как контракт между сервисами меняется без остановки потребителей. Вопрос отсеивает тех, кто видел настройку в чужом application.yml, но не сталкивался с несовместимой схемой на проде.
Как отвечать
Объясните механику. Реестр хранит схемы (чаще всего Avro, бывает Protobuf или JSON Schema) и выдаёт каждой числовой идентификатор. Сериализатор пишет в сообщение не схему, а служебный байт и этот идентификатор, дальше идёт полезная нагрузка. Потребитель по идентификатору забирает схему из реестра и десериализует. Отсюда компактные сообщения и общий контракт.
Второй смысл реестра: проверка совместимости при регистрации. Режим задаётся на subject: BACKWARD означает, что новый потребитель прочитает старые сообщения, FORWARD наоборот, FULL оба направления. Subject по умолчанию собирается из имени топика, и стратегию меняют, когда в одном топике живут разные типы событий.
По Spring дайте конкретику: в Spring Cloud Stream биндер Kafka настраивается сериализаторами Avro и адресом реестра, чтение в сгенерированный класс включается отдельным свойством, иначе приходит обобщённая запись. Автоматическую регистрацию схем на проде выключают, схемы катят отдельным шагом, как миграции базы.
Где спотыкаются
Добавляют обязательное поле без значения по умолчанию и ломают совместимость. Проверка при регистрации это отклонит, а если её обошли, потребители со старой схемой начнут падать на десериализации, и откатить уже нечего: сообщения лежат в топике.
Второе: оставляют автоматическую регистрацию включённой. Тогда любой сервис, собранный с локально поправленным классом, создаёт новую версию схемы прямо из приложения, и реестр перестаёт быть источником правды.
Третье: считают, что реестр гарантирует корректность данных. Он проверяет структуру, а не смысл: переименование поля это удаление старого и добавление нового, значения сами не переедут, и потребитель получит пустое поле вместо ошибки.