Strangler Fig: миграция с монолита на headless без downtime

Проблема: страх миграции рационален

Большинство историй провалов в enterprise-разработке имеют один корень: кто-то попытался переписать всё сразу.

«Big bang» миграция — когда команда останавливает разработку фич, планирует полный переезд, мигрирует все данные и делает cutover в фиксированную дату — одновременно максимизирует несколько рисков:

• Бизнес-риск: если что-то сломается, пострадает весь бизнес
• Риск сроков: full rewrite почти всегда занимает дольше плана
• Риск данных: одновременный перенос каталога, заказов, контента — вероятность ошибок высока
• SLA-риск: длинные миграционные окна создают риск downtime

Результат: команды либо бесконечно откладывают («будем мигрировать, когда будем готовы»), либо запускают миграцию и сталкиваются с болезненным откатом.

Стоимость бездействия

Но есть и стоимость немиграции:

• Frontend и backend остаются связанными — каждое изменение UI требует backend-участия
• Скорость релизов ограничена самым медленным компонентом
• Техдолг накапливается с каждым патч-слоем поверх монолита
• Найм под легаси-стек становится труднее с каждым годом

Вопрос не «мигрировать или нет». Вопрос: «как мигрировать, не рискуя бизнесом?»

Подход: паттерн Strangler Fig

Паттерн назван в честь тропического растения, которое постепенно обвивает дерево-хозяина — новая система растёт вокруг старой, трафик перенаправляется постепенно, и монолит естественно «отмирает» по мере того, как каждый компонент мигрирует.

Ключевой принцип: мы не заменяем монолит. Мы строим маршрут вокруг него — user journey за user journey.

Механизм: по фазам

Фаза 0: Подготовка

• Аудит текущих user journeys и их зависимостей от backend
• Определение API-контракта для первого journey к миграции (какие данные нужны, в каком формате)
• Baseline-метрики: скорость страницы, error rate, конверсия для целевого journey

Фаза 1: Первый journey за API-граничей

• Выбираем journey с высокой ценностью и низкой связностью (обычно: листинг категории или поиск)
• Строим новую реализацию на Next.js, потребляющую данные через API-адаптер
• API-адаптер транслирует между новым фронтом и существующим backend (Bitrix или другим)
• Пользователи этого не видят — работает параллельно

Фаза 2: Маршрутизация трафика

• Направляем небольшой % трафика (например, 5-10%) на новую реализацию
• Мониторим: latency, error rate, поведение пользователей, конверсия
• Сравниваем с baseline
• Откатываем, если что-то неожиданное — это одна команда в деплой-пайплайне

Фаза 3: Постепенное масштабирование

• Увеличиваем долю трафика по мере роста уверенности: 25% → 50% → 100%
• При 100% старая реализация этого journey уже не обслуживает трафик
• Монолит продолжает существовать — он просто «задушен» для этого journey

Фаза 4: Повторение

• Следующий journey: карточка товара, поиск, корзина/чекаут, личный кабинет
• Каждая миграция следует тому же паттерну
• Монолит сжимается; новая API-first система растёт

Что сохраняется на протяжении всего процесса

• Выручка: трафик перенаправляется постепенно, а не в момент единого cutover
• SLA: откат доступен на каждом этапе
• Существующие интеграции: API-адаптер общается с Bitrix — CRM, склад, 1С не затрагиваются в ранних фазах
• Ресурс команды: каждая фаза — ограниченный спринт, а не открытый rewrite

Ограничения (честно)

• Этот подход занимает дольше, чем big-bang миграция
• Поддержка API-адаптерного слоя добавляет engineering overhead в переходный период
• Команде нужна дисциплина в версионировании API-контрактов
• Если схема данных монолита сильно запутана, извлечение API-контрактов требует предварительного анализа

Типы доказательств для обоснования внутри компании

• Поэтапный roadmap с определением milestone и критериями отката
• Architecture blueprint с API-адаптерным слоем и механизмом маршрутизации
• Baseline + target метрики для каждой фазы (не «станет лучше», а «вот что измеряем»)

CTA (M3: Decision)

Если вы готовите архитектурное решение или вам нужен roadmap миграции для презентации на техсовете — предлагаем бесплатный 1-часовой архитектурный разбор.

Мы разберём текущее состояние, определим, какие journeys мигрировать первыми, и составим поэтапный план с явными точками отката.

Записаться на архитектурный разбор: https://webgoodpeople.com/ru/contact

Посмотреть продукт: https://webgoodpeople.com/ru/products/headless-next-elasticsearch