Несовместимое изменение схемы данных требует одновременного обновления всех потребителей. Какой поэтапный приём позволит избежать этого?
Используйте паттерн expand-contract: сначала расширьте схему и добавьте совместимый путь работы, затем постепенно переведите потребителей и только после этого удалите старую структуру. Это разделяет несовместимое изменение на несколько обратно совместимых этапов и не требует единого релиза всех участников.
Подход появился как ответ на необходимость изменять схемы данных в системах, которые должны работать непрерывно. При тесно связанных релизах изменение столбца или формата записи могло немедленно сломать ещё не обновлённых потребителей.
Поэтапная миграция переносит несовместимость в управляемый момент, когда старый путь уже не используется. Это особенно важно для распределённых систем, где обновление компонентов происходит независимо.
Предположим, поле name нужно заменить на full_name. Если сначала переименовать или удалить name, старые версии приложения перестанут читать данные. Если сначала выпустить приложение, использующее только full_name, новая версия может столкнуться со строками, где это поле ещё не заполнено.
Неверная последовательность приводит к ошибкам чтения, потере записей, расхождению данных или невозможности безопасно откатить релиз. Простое увеличение времени между релизами проблему не решает: старые и новые версии должны временно сосуществовать.
Сначала выполняется расширение: добавляется новое поле или новый формат, не нарушающий работу старых потребителей. На этом этапе старая структура остаётся доступной, а новая может заполняться при новых операциях или отдельным процессом переноса.
Затем обновляются потребители. На переходном этапе приложение может читать новое значение с резервным чтением старого, а при записи поддерживать оба представления. После проверки и завершения миграции чтение и запись переводятся только на новую структуру.
Последним выполняется свёртывание: удаляются старое поле, переходная логика и код совместимости. Удаление допустимо только после подтверждения, что старые потребители, фоновые задачи и отчёты больше не обращаются к прежней структуре.
Двойная запись повышает риск расхождения значений. Поэтому нужны контроль полноты переноса, проверка расхождений, идемпотентность повторного запуска и понятный план восстановления. Если изменение затрагивает семантику данных, одной совместимости схемы недостаточно: необходимо отдельно проверить, что старое и новое представления означают одно и то же.
В системе заказов требовалось заменить один адрес доставки строкой на структурированный адрес. Рассматривались два варианта: остановить запись на время миграции или сразу заменить формат во всех компонентах. Остановка упрощала согласованность, но была неприемлема для бизнеса; единый релиз был быстрее, но создавал высокий риск отказа из-за независимого обновления потребителей.
Был выбран expand-contract. Добавили структурированные поля, начали заполнять их для новых заказов и фоново перенесли старые данные, затем приложение стало читать новый формат с контролируемым резервным чтением старого. После проверки расхождений старый формат удалили.
Такой вариант потребовал временной дополнительной логики и мониторинга, но позволил выполнять миграцию без остановки сервиса и сохранить возможность поэтапного отката приложения.
Не всегда. Оно безопасно только для потребителей, которые игнорируют неизвестные поля, а для записи нужно учитывать ограничения, значения по умолчанию и поведение старых версий. Если новое поле объявлено обязательным на уровне схемы до обновления всех записывающих клиентов, старые версии могут перестать создавать записи.
Перенос обычно выполняют отдельным управляемым процессом, который можно возобновить после сбоя и безопасно повторить. Нельзя бездумно помещать большой перенос в один релиз или транзакцию: это может вызвать длительные блокировки, нагрузку на хранилище и проблемы с откатом. Нужны порции, контроль прогресса и проверка результата.
После этапа расширения схема специально поддерживает старую и новую версии, поэтому приложение можно вернуть к старому коду без немедленного восстановления прежней схемы. После свёртывания старые структуры уже удалены, и откат старого приложения становится невозможным без отдельного обратного изменения. Поэтому необратимые действия выполняют только после подтверждения завершения перехода всех потребителей.