😡 Не сломаться по щелчку пальцев

Сегодня начну с истории, которая произошла несколько лет назад. Коллега сидел над разбором инцидента: смотрел документацию, изучал логи и то и дело задумчиво повторял: "Компатибл…" Но в какой-то момент он воскликнул: "Компатибл-компатибл… Нифига не компатибл!" 🪄

Оказалось, что причиной проблемы было нарушение совместимости форматов данных. То ли какое-то из ранее предусмотренных полей было удалено, то ли переименовано — детали стёрлись в памяти.

Но я вспомнил эту историю неспроста. В последние дни занимаюсь решением, в котором используется несколько независимых кластеров Kafka от разных команд. И надо заранее подумать, как уберечь систему от таких поломок.

Вопросы освежаю сам для себя и заодно хочу тезисно зафиксировать и поделиться с вами. Погнали! 😂

-ˋˏ✄┈┈┈┈┈┈┈┈┈┈┈┈┈┈

В распределённых системах выделяют два базовых подхода: обратная совместимость (backward compatibility) и прямая совместимость (forward compatibility). А когда нарушаются правила контракта, пора поднимать версию.


🔶 Версионирование

Версионирование — это единственный способ договориться об изменениях в контракте между независимыми сервисами. Без него вы никогда не узнаете, кто именно пишет или читает данные по устаревшим правилам. Но это не всё. 🤷‍♂️

Даже если весь код лежит в одном репозитории и им владеет одна команда, брокер сообщений всегда создаёт временную "дыру" 🕐 между записью и чтением. Сервис-писатель может быть переведён на новую схему сегодня, а старый сервис-читатель дотянет до следующего релиза только через месяц.

✅ Что с этим делать
Идентификатор схемы (Schema ID) или номер версии формата передаётся в заголовках сообщения или кладётся в полезную нагрузку. Де-факто стандарт для Kafka — проверка через Schema Registry, но финальная реализация зависит от архитектурных решений конкретной компании.


🔶 Совместимость

▌ 🔙 Обратная совместимость (Backward)
Приложение на новой версии должно уметь читать данные, созданные по старой схеме.

✅ Что можно делать со схемой:
— удалять поля;
— добавлять новые необязательные поля;
— делать обязательные поля необязательными.

❗️ Кто обновляется первым: читатели (консьюмеры). Писатели (продюсеры) могут подождать.

▌ 🔜 Прямая совместимость (Forward)
Приложение на старой версии должно уметь работать с данными, созданными по новой схеме.

✅ Что можно делать со схемой:
— добавлять новые поля;
— удалять необязательные поля;
— делать необязательные поля обязательными.

❗️ Кто обновляется первым: писатели (продюсеры). Читатели (консьюмеры) могут подождать.

#интеграции #kafka #api #сервисы #форматы #данные