🟢 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. Які інструменти використовуються для оркестрації мікросервісів]]