Dlaczego „Big Bang Rewrite” prawie zawsze kończy się katastrofą#
Większość dojrzałych firm, które zbudowały swoją pozycję na rynku, staje w pewnym momencie przed ścianą długu technologicznego. 6-, 8- lub 10-letni monolit o objętości 400k+ linii kodu staje się wąskim gardłem:
- Release'y trwają tygodniami ze względu na strach przed niekontrolowanymi regresjami,
- Wdrożenie nowego developera do bazy kodu zajmuje miesiące,
- Prosta zmiana w kalkulacji rabatów psuje wystawianie faktur w module księgowym.
Typową reakcją zespołu technologicznego jest postulat: „Przepiszmy wszystko od nowa w mikroserwisach!” (tzw. Big Bang Rewrite).
Doświadczenie inżynieryjne uczy, że w ponad 90% przypadków podejście to prowadzi do katastrofy:
- Ruchomy cel (Moving Target): Podczas gdy zespół przez 18 miesięcy przepisuje stary system, konkurencja wprowadza nowe funkcje, a rynek wymaga kolejnych zmian biznesowych.
- Podwójny koszt utrzymania: Firma musi opłacać dwa zespoły – jeden gaszący pożary na produkcji i drugi budujący „nowy wspaniały świat”.
- Ryzyko wdrożenia zerowego dnia: Dzień przełączenia ruchu ze starego systemu na nowy staje się koszmarem z setkami ukrytych bugów, które nie wyszły w testach stagingowych.
Alternatywą o udowodnionej w warunkach bojowych skuteczności jest Wzorzec Strangler Fig (Duszący Figowiec).
Anatomia wzorca Strangler Fig#
Nazwa wzorca pochodzi od figowców-dusicieli, które kiełkują w koronach drzew, zapuszczają korzenie w dół pnia i z biegiem lat stopniowo oplatają drzewo-gospodarza, aż ostatecznie przejmują jego miejsce.
W architekturze oprogramowania oznacza to: stopniowe wycinanie i zastępowanie poszczególnych domen monolitu nowymi mikroserwisami, podczas gdy stary monolit bezustannie obsługuje klientów i generuje przychód.
Faza 1: Monolit za Proxy
[Klienci / API] ──► [Traefik Reverse Proxy] ──(100% ruchu)──► [Stary Monolit]
Faza 2: Pierwszy Strangler Slice (np. Koszyk / Fakturowanie)
[Klienci / API] ──► [Traefik Reverse Proxy]
├──(90% ruchu)──► [Stary Monolit]
└──(10% ruchu)──► [Nowy Moduł DDD (Vertical Slice)]
│ (Event Sync)
▼
[RabbitMQ / CDC Outbox]
Faza 3: Pełna Emancypacja
[Klienci / API] ──► [Traefik Reverse Proxy] ──(100% domen)──► [Nowa Architektura]
[Monolit wyłączony]
4 Filarowe Zasady Bezprzestojowej Dekompozycji#
1. Brzegowy Reverse Proxy (Edge Routing)#
Pierwszym krokiem nie jest refaktoryzacja kodu, lecz wstawienie inteligentnego routera brzegowego (np. Traefik, Envoy lub NGINX) przed całą infrastrukturę.
Wszystkie żądania HTTP od przeglądarek, aplikacji mobilnych i partnerów B2B trafiają najpierw do proxy. Dzięki temu możemy przekierowywać konkretne ścieżki (np. /api/v1/invoices/* lub /checkout/*) do nowych usług bez konieczności modyfikacji po stronie klientów.
2. Wyznaczanie granic domenowych (Domain-Driven Design)#
Największym błędem jest dzielenie monolitu według warstw technicznych (np. wydzielenie „bazy danych” lub „warstwy logowania”).
Dekompozycję prowadzimy pionowo (Vertical Slice) w oparciu o analizę Bounded Contexts z Domain-Driven Design:
- Wybieramy domenę o wysokim ROI i stosunkowo niskiej liczbie zależności w głąb bazy (np. generowanie dokumentów PDF, integracje kurierskie, system notyfikacji).
- Cała logika biznesowa danej domeny zostaje zamknięta w autonomicznym module ze swoją własną bazą danych.
3. Synchronizacja danych: Wzorzec Outbox & Change Data Capture (CDC)#
Jak zapewnić spójność danych, gdy monolit i nowy mikroserwis muszą współdzielić informacje o zamówieniach lub klientach?
Nigdy nie łącz nowej usługi bezpośrednio ze starą bazą SQL (unikać Shared Database Anti-Pattern). Zamiast tego wdrażamy Transactional Outbox Pattern:
- W tej samej transakcji bazodanowej, która zapisuje stan encji, zapisujemy zdarzenie w tabeli
outbox_events. - Dedykowany proces tła (lub Debezium CDC) odczytuje tabelę i publikuje zdarzenie do brokera wiadomości (RabbitMQ / Kafka).
- Nowy mikroserwis asynchronicznie aktualizuje swoją zoptymalizowaną projekcję danych.
4. Consumer-Driven Contract Testing#
Aby zagwarantować, że nowy serwis nie złamie kompatybilności wstecznej, definiujemy ścisłe kontrakty API oparte o OpenAPI oraz testy kontraktowe (np. Pact). Pipeline CI/CD automatycznie weryfikuje, czy nowo wdrożony endpoint spełnia oczekiwania wszystkich dotychczasowych konsumentów.
Checklista Architektoniczna: Czy Twój monolit jest gotowy na Strangler Fig?#
Przed przystąpieniem do migracji upewnij się, że posiadasz:
- [x] Scentralizowany monitoring APM (logi, tracing distributed oparty o OpenTelemetry),
- [x] Brzegowy reverse proxy z dynamicznym przeładowaniem reguł bez restartu (np. Traefik),
- [x] Wydzielony broker zdarzeń (RabbitMQ / Kafka) z obsługą Dead-Letter Exchanges,
- [x] Zautomatyzowane pipeline'y CI/CD pozwalające na wdrożenie w czasie poniżej 10 minut,
- [x] Środowisko testowe z zanonimizowanymi danymi produkcyjnymi.
Podsumowanie#
Wzorzec Strangler Fig zamienia ryzykowny, paraliżujący biznes projekt „przepisywania od nowa” w przewidywalny, mierzalny proces inżynieryjny. Pierwsze efekty biznesowe – skrócenie czasu release'u i eliminację długu technologicznego – Zarząd widzi już po 3–4 tygodniach od wycięcia pierwszej domeny, a nie po 18 miesiącach niepewności.
