Самый простой способ изменить интерфейс между системами — договориться, что старая версия больше не работает. В маленькой системе это иногда нормально.
Но с ростом числа клиентов и интеграций такая договорённость превращается в проект синхронизации: все должны обновиться почти одновременно, иначе кто-то перестанет работать.
Какую проблему мы решаем
Backward compatibility означает, что новая версия системы продолжает понимать старый контракт хотя бы в течение переходного периода.
Можно добавить новое поле, сохранив старое; поддержать две версии API; сначала научить потребителей новому формату и только потом убрать старый.
Главная идея — разделить момент изменения поставщика и момент миграции каждого потребителя.
Что получает бизнес
Компания получает возможность развивать продукт без общей «даты большого переключения» для всех клиентов и партнёров.
Это уменьшает стоимость координации. Партнёры могут обновляться в своём цикле, мобильные приложения — с учётом магазинов приложений, внутренние команды — без аварийного перепланирования своих roadmap.
Второй эффект — ниже риск изменения. Если новый контракт оказался проблемным, старые потребители всё ещё продолжают работать.
Для бизнеса совместимость — это прежде всего свобода менять одну часть экосистемы, не превращая изменение в общую миграционную кампанию.
Что получает команда
Команды получают возможность выпускать изменения независимо и проводить миграцию постепенно.
Но приходится проектировать контракты осторожнее: различать additive и breaking changes, отслеживать версии, измерять использование старого интерфейса и заранее планировать deprecation.
Что получает клиент
Клиент или партнёр не вынужден срочно менять интеграцию только потому, что поставщик обновил внутреннюю систему.
Он получает предсказуемый период миграции и понятное уведомление о том, что старая версия будет отключена.
Чем мы за это платим
Цена — временное сосуществование нескольких контрактов и дополнительный код совместимости.
Если старые версии никогда не удалять, система постепенно превращается в музей исторических решений. Поэтому совместимость должна иметь жизненный цикл: объявление, переходный период, наблюдение за использованием и удаление.
Когда backward compatibility не нужна
Если поставщик и потребитель разворачиваются одной командой как единое целое, синхронное изменение может быть дешевле поддержки нескольких контрактов.
Не каждое внутреннее изменение обязано получать публичную политику версий.
Что стоит спросить перед решением
- Сколько независимых потребителей у этого контракта?
- Можем ли мы обновить их одновременно?
- Как долго должна жить старая версия?
- Видим ли мы, кто ещё ей пользуется?
- Как выглядит безопасный план удаления совместимости?
В итоге
Backward compatibility — не попытка никогда ничего не ломать. Это способ управлять моментом разрыва.
Для бизнеса ценность в том, что изменение одной системы перестаёт требовать одновременной мобилизации всей экосистемы вокруг неё.