Очереди хорошо уменьшают прямую связанность между системами. Отправителю не нужно знать всех получателей. Но это не означает, что зависимости исчезают.
Если событие «Заказ создан» меняет структуру, смысл поля или обязательность данных, десятки потребителей могут неожиданно перестать его понимать. В такой архитектуре простой rename поля иногда становится организационной миграцией.
Какую проблему мы решаем
Schema Registry хранит формальные схемы событий и их версии. Продюсеры и потребители могут проверять, соответствует ли сообщение ожидаемому контракту и совместима ли новая версия со старой.
Вместо надежды «кажется, никто это поле не использует» появляется проверяемое правило: допустимо ли удалить поле, изменить тип или сделать ранее необязательное значение обязательным.
Registry не отменяет коммуникацию между командами. Он переносит часть договорённостей из документации и памяти людей в механизм, который можно автоматически проверить.
Что получает бизнес
Главный эффект — снижение риска скрытой стоимости изменений.
Когда одно событие используется множеством продуктов, несовместимое изменение может остановить не один сервис, а сразу несколько бизнес-процессов. Формальная проверка совместимости уменьшает вероятность такого каскада.
Это также помогает масштабировать количество команд. Каждое изменение не требует вручную находить всех потребителей и договариваться с ними о синхронном релизе.
Бизнес получает более дешёвую эволюцию интеграционного слоя — но только если правила схем действительно соблюдаются всеми участниками.
Что получает команда
Команда получает версионируемый контракт и раннюю обратную связь. Несовместимость можно обнаружить в CI или при публикации схемы, а не после падения чужого consumer.
Проще генерировать типы, документировать события и понимать историю их развития.
Но Schema Registry не решает смысловую несовместимость автоматически. Поле может остаться строкой и формально пройти проверку, хотя бизнес-смысл изменился полностью.
Что получает клиент
Клиент почти никогда не видит Schema Registry напрямую. Он получает меньше интеграционных сбоев и меньше ситуаций, когда одна внутренняя миграция ломает заказ, уведомление или расчёт в другой части системы.
Для внешних клиентов и партнёров эффект особенно заметен там, где внутренние события в итоге питают API, отчёты и уведомления.
Чем мы за это платим
Появляется ещё один инфраструктурный компонент и правила работы с ним. Нужно выбрать формат схем, режимы совместимости и встроить проверки в delivery pipeline.
Команды должны перестать относиться к событию как к внутренней структуре одного сервиса. Как только событие публично внутри компании, его изменение требует дисциплины.
Есть риск и обратной крайности: страх изменить схему вообще. Совместимость должна помогать развитию, а не превращать каждое старое поле в вечный legacy.
Когда Schema Registry не нужен
Если события используются одной командой и число интеграций невелико, простая договорённость и тесты могут быть дешевле отдельной платформы.
Registry начинает окупаться, когда события живут долго, потребителей много, команды независимы, а цена несовместимого изменения заметна.
Что стоит спросить перед решением
- Сколько независимых потребителей у ключевых событий?
- Кто владеет контрактом события и принимает решения об изменениях?
- Какая совместимость нужна: backward, forward или обе?
- Можно ли автоматически блокировать несовместимое изменение до production?
- Как мы удаляем устаревшие поля и версии, чтобы контракт не рос бесконечно?
В итоге
Schema Registry нужен не потому, что события должны быть «строго типизированы». Он нужен, когда изменение одного сообщения стало риском для многих независимых систем.
Для бизнеса это способ уменьшить цену координации и не превращать развитие event-driven платформы в цепочку неожиданных поломок.