Представим сеть спортивных клубов, где заморозить абонемент можно только через администратора. Компания хочет вынести этот сценарий в личный кабинет. Переписывать ради него весь учёт посещений и расчётов дорого, но новая форма поверх старой программы тоже мало поможет: изменить период, отменить заявку и объяснить клиенту остаток дней по-прежнему трудно.
Strangler Pattern позволяет постепенно передавать функции новой системе, пока остальная работа остаётся в прежней. Польза появляется, когда выбранный участок действительно становится проще менять. Количество новых сервисов здесь ничего не доказывает: можно построить современный фасад и сохранить за ним все прежние ограничения.
Выбрать часть, которую можно довести до результата
Для заморозки нужно определить весь путь: кто вправе её запросить, когда она начинается, как влияет на срок абонемента и что происходит при отмене. Экран подачи заявки — лишь один вход. Есть ещё администратор клуба, задания по расписанию и обращения поддержки.
Граница не обязана охватывать всю компанию. Но у выбранного сценария должны быть проверяемый результат и владелец. В описании постепенного замещения у Мартина Фаулера важна возможность двигаться небольшими законченными изменениями, продолжая развивать продукт. Сам подход не требует превращать каждую функцию в микросервис.
До начала разработки полезно выяснить, что именно тормозит работу: общий выпуск, непонятные правила, старая библиотека или необходимость вручную исправлять записи. Если ограничение находится в договорённостях, перенос того же кода на новую платформу не устранит его. Иногда сначала достаточно выделить модуль внутри существующего приложения.
Найти входы, которые обойдут новый маршрут
Фасад может направлять запросы на заморозку в новую реализацию, а остальные — в старую. Такой механизм описывает Azure Architecture Center. Однако маршрутизатор видит только проходящие через него обращения. Ночное задание, напрямую меняющее таблицу абонементов, продолжит работать по прежним правилам.
Поэтому составляют перечень источников изменений, включая импорт, служебные экраны и повторную обработку сообщений. У каждого должен появиться согласованный путь к владельцу операции. Временный слой перевода помогает сохранить старым потребителям понятный контракт, не заставляя новую систему повторять все особенности прежней модели.
Сам фасад тоже требует сопровождения. Ошибка маршрута не должна отправлять одну заявку попеременно двум исполнителям. Проверяются полномочия, идентификаторы операций, задержки и поведение при отказе новой стороны. Автоматически повторить изменяющий запрос в старой системе безопасно далеко не всегда.
Копирование базы не передаёт право изменять данные
Пока новую систему наполняют историей, старая продолжает принимать обращения. Одной выгрузки недостаточно: между началом копирования и переключением появляются изменения. Нужны способ их доставить, контроль отставания и сверка результата. Руководство AWS отдельно рассматривает сосуществование систем и синхронизацию данных при таком переходе.
Сверять стоит не только количество строк. Для клуба важны доступные дни, действующие периоды заморозки, отменённые заявки и связь с конкретным абонементом. Две базы с одинаковым числом записей могут по-разному разрешать посещение завтра.
Для каждой операции определяют, какая сторона принимает окончательное изменение. Двойная запись из приложения в обе базы без согласованного восстановления создаёт новый риск: одна запись прошла, другая нет. Точный способ перехода зависит от системы — доставка изменений, временное ограничение записи или другое явно спроектированное согласование. Универсальной безопасной кнопки «писать везде» нет.
Что делать с заявкой, начатой до переключения
Заявка на заморозку может ещё ожидать подтверждения, когда новый маршрут уже включён. Нужно выбрать: завершать её в прежней реализации или переносить состояние вместе с ответственностью. Оба варианта требуют найти незавершённую работу и понимать, куда придёт следующий шаг.
В нашем примере маршрут можно закрепить за заявкой. Но принадлежность к старой системе не должна сохраняться бесконечно: часть заявок зависнет или вернётся после исправления. Понадобятся срок разбора исключений, владелец и способ безопасно продолжить обработку. Иначе обычный поток переедет, а несколько старых случаев будут годами удерживать всю платформу.
Проверять новую логику на копиях входных данных полезно, если сравнение не меняет реальное состояние. Два параллельных расчёта допустимы; две команды продлить один абонемент — уже две операции. У тестовой стороны должны быть исключены рабочие побочные эффекты.
Обратный маршрут заканчивается раньше, чем миграция
До появления новых записей вернуть запросы старому исполнителю иногда просто. После записи состояния, которого он не понимает, возврат может потребовать преобразования или исправления вперёд. Обновление программы и обратимость её данных — разные проверки; эту проблему подробно разбирает Amazon Builders’ Library.
Команде нужен не общий пункт «есть откат», а конкретная граница: до какого действия он безопасен, кто принимает решение после неё и что показывать клиенту во время восстановления. Нельзя отменить подтверждённую заморозку только потому, что удобнее вернуть старый код.
Закрыть старую функцию, а не только открыть новую
У перенесённого сценария проверяют отсутствие старых вызовов и незавершённых заданий, возможность поддержки найти историю и готовность новой команды восстановить работу. Затем удаляют старые задания, лишние доступы и ненужные интеграции. Архив может оставаться доступным для чтения, не сохраняя прежний исполнитель операций.
Временная архитектура имеет собственную стоимость: две эксплуатации, сверка, обучение поддержки, изменения на границе. Для небольшого изолированного компонента разовая замена может оказаться дешевле. Но если выбран постепенный переход, его бюджет должен включать завершение. Для клуба результатом будет самостоятельная работа с заморозкой и действительно выключенная старая функция, а не ещё один постоянно поддерживаемый личный кабинет.