Как работает эволюция схем данных в AVRO? В Мир Plat.Form задача эволюции схемы данных AVRO стала острой на этапе внедрения новой интеграции между сервисами через Kafka. Вот 5 ключевых мыслей от коллег: 1️⃣ Почему важна эволюция схемы: сообщения в Kafka хранятся неделями, продюсеры и консьюмеры обновляются по-разному, и всем участникам нужно уметь читать разные версии схем данных, не ломая совместимость. 2️⃣ Версионирование топиков — не выход: изоляция схем через _v1, _v2 работает легко только внутри одной команды, а для кросс-команд, с частыми изменениями и переключениями, процессы становятся слишком громоздкими. 3️⃣ Schema Registry как стандарт: Confluent Schema Registry хранит версии схем, контролирует их совместимость (BACKWARD, FORWARD, FULL), автоматически определяет, как и что можно менять — и это необходимо для устойчивой работы. 4️⃣ Без Schema Registry: для временного решения можно добавить номер схемы прямо в хедер Kafka, чтобы на этапе десериализации легко сопоставлять данные и схему, не дорабатывая сериализатор (и не перелопачивая legacy). 5️⃣ Рекомендация: несмотря на устойчивость самописных решений с заголовками Kafka, для новых проектов рекомендуем переходить на Schema Registry — это автоматизация, минимизация ошибок и простота поддержки. 🔗 Подробнее читай в статье Владислава Коневского на Хабр.