Strangler Fig: підміна фрагмента legacy-коду

Strangler Fig — поступова підміна, не big-bang rewrite

Strangler Fig pattern дозволяє новому фрагменту поступово перехоплювати частину поведінки навколо legacy-системи. Старий і новий paths певний час coexist, а кожен крок має явну boundary, routing rule, ownership, verification і rollback.

Назва pattern не виправдовує приховану міграцію. Якщо немає способу зрозуміти, який path виконався, або rollback залишає подвійні записи, це не контрольована strangler slice.

Мінімальна модель strangler slice

Етапи підміни

1. Зафіксуйте current behavior і seam для одного fragment.
2. Додайте нову реалізацію за наявним контрактом, не розширюючи scope.
3. Визначте routing або feature boundary з явною default поведінкою.
4. Перевірте old і new path на однакових representative inputs.
5. Спостерігайте discrepancy, error rate та side effects до розширення охоплення.
6. Поступово збільшуйте slice лише після risk gate.
7. Видаляйте legacy code тільки після exit criteria та підтвердженого rollback window.

Небезпеки coexistence

• два paths записують один ресурс або відправляють два notifications;
• новий path має іншу timezone, rounding, retry або idempotency semantics;
• routing rule залежить від неперевіреного flag або configuration precedence;
• rollback перемикає код, але не повертає вже змінений state;
• legacy path продовжує отримувати traffic, але його більше ніхто не спостерігає.

Strangler slice record

# STRANGLER_SLICE.md

## Fragment and boundary
## Legacy path
## New path
## Routing rule
## Coexistence and side effects
## Verification evidence
## Rollback procedure
## Exit criteria
## Owner and open risks