Какую проблему мы решаем
Чем больше потребителей у таблицы, события или API, тем опаснее изменение, которое ломает старый формат. Если новая колонка, новое имя поля или новая структура требуют общего переключения, релиз превращается в организационную операцию.
Проблема не в самой миграции, а в необходимости синхронизировать слишком много независимых частей в один момент.
Как работает Expand–Contract
На этапе expand система становится совместимой и со старым, и с новым способом работы. Добавляется новое поле, новый контракт или новая структура, но старое ещё остаётся доступным.
Затем потребители постепенно переходят на новый вариант. Только когда старый путь действительно больше не используется, начинается contract: старую структуру удаляют.
Вместо одного большого риска появляется несколько меньших шагов, каждый из которых можно наблюдать и при необходимости остановить.
Что получает бизнес
Главная выгода — меньше релизов, требующих общей даты и большого количества координации. Команды могут мигрировать в своём темпе, а критическое изменение не обязано становиться событием для всей компании.
Снижается риск простоя из-за несовместимости и легче откатывать отдельные шаги. Это особенно ценно в системах, где вынужденный synchronized cutover влияет на продажи или операции.
Что получает команда
Команды получают временное окно совместимости. Можно сначала подготовить инфраструктуру, затем обновить код чтения и записи, после чего безопасно убрать старый путь.
Но появляется дисциплина: нужно отслеживать использование старого контракта, не забывать завершать миграцию и явно управлять переходным состоянием.
Что получает клиент
Клиент получает меньше технических окон и меньше ситуаций, когда все должны обновиться одновременно. Для внешних интеграций это означает возможность мигрировать по согласованному периоду, а не в одну ночь.
Чем мы за это платим
Во время перехода система сложнее: некоторое время существуют два поля, два формата или два пути обработки. Нужно поддерживать совместимость, тестировать оба варианта и следить, чтобы данные не расходились.
Если contract постоянно откладывать, временная совместимость превращается в постоянный legacy.
Когда не нужно
Если изменение полностью локально и имеет одного контролируемого потребителя, многоэтапная миграция может быть избыточной. Иногда простой атомарный change действительно дешевле.
Подход нужен там, где невозможно или слишком рискованно обновить всех потребителей одновременно.
Что стоит спросить перед решением
- Сколько независимых потребителей затрагивает изменение?
- Можно ли некоторое время поддерживать старый и новый формат одновременно?
- Как поймём, что старый путь больше никто не использует?
- Что будет источником истины во время переходного периода?
- Кто отвечает за завершение contract-этапа?
В итоге
Expand–Contract не делает миграцию бесплатной. Он меняет форму риска: вместо одного большого переключения компания оплачивает временную совместимость.
Для бизнеса это часто выгодный обмен — немного больше технической работы сегодня ради отсутствия общего дня, когда ошибка может остановить сразу всех.