🟢 Junior Level

Strangler Fig (Удущающий инжир) — паттерн для постепенной миграции с монолита на микросервисы.

Аналогия из природы: инжир растёт вокруг дерева, постепенно заменяя его, пока дерево не исчезнет.

Монолит: [==============]

Шаг 1:   [==========] + [User Service]
Шаг 2:   [======] + [User Service] + [Order Service]
Шаг 3:   [==] + [User Service] + [Order Service] + [Payment Service]
Шаг 4:   [User Service] + [Order Service] + [Payment Service]

---

🟡 Middle Level

Как работает

1. API Gateway перед монолитом:

Клиент → API Gateway → Монолит (по умолчанию)
                     → Новый сервис (если есть)

2. Постепенная миграция:

1. Вынести User функциональность → User Service
2. Роутить /api/users → User Service
3. Вынести Order → Order Service
4. Роутить /api/orders → Order Service
5. Продолжать пока монолит не исчезнет

Типичные ошибки

1. Big bang миграция:

   2 года разработки → всё сразу → высокий риск
   Strangler: низкий риск, пошаговая миграция
   

---

🔴 Senior Level

Dual write pattern

При миграции данных:
1. Писать в монолит И в новую БД
2. Читать из новой БД
3. Сверять данные
4. Убрать запись в монолит

// Dual write проблема: если запись в старую систему успешна, а в новую — нет, // данные рассинхронизируются. Решение: Outbox pattern или CDC.

Production Experience

Feature flags:

@Value("${feature-flag.use-new-user-service:false}")
private boolean useNewUserService;

// Feature flags — отдель паттерн, но помогает при Strangler Fig:
// можно переключать трафик на новую систему без деплоя.

@GetMapping("/users/{id}")
public User getUser(@PathVariable Long id) {
    if (useNewUserService) {
        return newUserService.getUser(id);
    }
    return monolith.getUser(id);
}

Best Practices

✅ API Gateway с роутингом
✅ Feature flags
✅ Dual write при миграции данных
✅ Пошаговая миграция

❌ Big bang миграция
❌ Без feature flags
❌ Без мониторинга во время миграции

---

🎯 Шпаргалка для интервью

Обязательно знать:

• Strangler Fig — постепенная миграция с монолита на микросервисы
• API Gateway перед монолитом — роутит на новые сервисы или монолит
• Пошаговая миграция: вынести функциональность → роутить на новый сервис → повторять
• Dual write pattern при миграции данных — писать в старую и новую БД
• Feature flags — переключение трафика без деплоя
• Outbox pattern или CDC решают dual write problem (рассинхронизация)
• Big bang миграция = 2 года разработки → всё сразу → высокий риск

Частые уточняющие вопросы:

• Что такое dual write problem? Запись в старую систему успешна, в новую — нет, данные рассинхронизируются — решение: Outbox или CDC.
• Зачем feature flags? Можно переключать трафик на новую систему без деплоя, быстрый rollback.
• Как мониторить миграцию? Сравнивать ответы старой и новой системы, метрики ошибок, latency.
• Порядок миграции? Начинать с наименее критичной функциональности, постепенно к основной.

Красные флаги (НЕ говорить):

• “Big bang миграция быстрее” — нет, выше риск, сложнее откат
• “Dual write без Outbox — норм” — нет, данные рассинхронизируются
• “Feature flags не нужны, можно задеплоить” — без feature flags rollback = новый деплой
• “Миграция без мониторинга” — нет, нужно видеть проблемы в реальном времени

Связанные темы:

• [[14. Какие проблемы возникают при использовании общей базы данных]]
• [[13. Что такое паттерн Database per Service]]
• [[9. Что такое API Gateway и какие задачи он решает]]
• [[3. Как реализовать распределённые транзакции в микросервисах]]
• [[26. Какие инструменты используются для оркестрации микросервисов]]