- Das Strangler-Fig-Muster legt eine Fassade vor die alte Anwendung und leitet Anfragen schrittweise auf neue Services um, bis das Altsystem überflüssig ist.
- Martin Fowler beschrieb das Muster 2004 und benannte es 2019 in Strangler Fig Application um, weil der reine Begriff Strangler zu martialisch klang.
- Die größte Falle ist keine technische: Ohne festen Fahrplan bekommt die Ablösung kein Enddatum und läuft unbegrenzt neben dem Altsystem weiter.
- Für kleine Systeme, die sich in wenigen Wochen komplett ersetzen lassen, lohnt sich der Aufwand der Übergangsarchitektur nicht.
1. Was das Strangler-Fig-Muster ist
Fowler beobachtete Würgefeigen in den Regenwäldern von Queensland: Die Pflanze keimt in den oberen Ästen eines Wirtsbaums, wächst mit Luftwurzeln langsam nach unten und umschließt den Stamm, bis der Wirtsbaum irgendwann abstirbt und verrottet. Übrig bleibt eine Struktur, die von außen wie ein einzelner Baum aussieht, aber komplett aus der neuen Pflanze besteht. 2019 änderte Fowler den Titel seines ursprünglichen Artikels von "Strangler Application" zu "Strangler Fig Application", weil der reine Begriff Strangler ohne die botanische Metapher unnötig gewalttätig wirkte.
Technisch überträgt sich das Bild auf eine Fassade: eine Schicht, die zwischen Client-Anwendung, Altsystem und neuen Services sitzt und Anfragen weiterleitet. Am Anfang gehen fast alle Anfragen an das Altsystem, die Fassade fällt kaum auf. Mit jeder migrierten Funktion übernimmt das neue System mehr, bis das Altsystem irgendwann keine Anfragen mehr bekommt und abgeschaltet werden kann. Die Fassade selbst verschwindet am Ende meist wieder, wenn Clients direkt mit dem neuen System sprechen.
Der Unterschied zum Big-Bang-Rewrite ist nicht nur Tempo, sondern Risiko. Beim Rewrite hängt alles an einem einzigen Cutover-Termin, an dem das neue System auf einmal funktionieren muss. Beim Strangler-Fig-Muster ist jede migrierte Domäne für sich rückrollbar, weil das Altsystem bis zum Schluss lauffähig bleibt.
2. Wie Fassade und Routing funktionieren
Die vier Phasen
Die Fassade durchläuft vier Phasen. Zuerst wird sie zwischen Client und Altsystem geschoben und leitet vorerst alles unverändert weiter, ohne selbst am Verhalten etwas zu ändern. In der zweiten Phase übernimmt ein erster neuer Service eine klar abgegrenzte Domäne, und die Fassade beginnt, genau diese Anfragen dorthin umzuleiten, während der Rest weiter beim Altsystem bleibt. Das wiederholt sich Domäne für Domäne, bis in der dritten Phase keine Anfrage mehr das Altsystem erreicht und es abgeschaltet werden kann. In der vierten Phase entfernt man die Fassade selbst und verbindet den Client direkt mit dem neuen System, weil sie dann nur noch eine unnötige Zwischenstation wäre.
Was die Fassade in einem Node-System sein kann
In einem gewachsenen Express- oder Meteor-System muss die Fassade kein neues Bauteil sein. Oft reicht eine pfadbasierte Weiterleitung im Reverse Proxy, etwa nginx oder ein Cloud-Load-Balancer, der bestimmte Routen an den neuen Service schickt und alle anderen unverändert beim Monolithen belässt. Wo Endpunkte nicht sauber genug getrennt sind, übernimmt ein schlanker Gateway-Service diese Aufgabe im Code und kann Anfragen bei Bedarf zusätzlich umformen, bevor er sie weiterreicht. Das ist reguläre Softwareentwicklung, kein Nebenprojekt, und die Fassade selbst sollte deshalb schlank bleiben und nicht zum neuen Monolithen werden, den später wieder jemand ablösen muss.
Aus der Praxis: Fowler nennt die Trennstellen zwischen Modulen Seams. Der naheliegende Fehler ist, mit dem nervigsten Teil der Anwendung anzufangen, weil er im Alltag am meisten wehtut. Sinnvoller ist die Domäne mit den wenigsten Abhängigkeiten zu anderen Modulen: Dort schneidet die Fassade am saubersten, und das Team hat früh einen sichtbaren Erfolg, der die nächste, schwierigere Domäne rechtfertigt.
3. Wann das Muster passt, und wann nicht
Das Strangler-Fig-Muster passt, wenn ein System zu groß oder zu geschäftskritisch ist, um es für einen Rewrite anzuhalten, und wenn sich Anfragen technisch an einer Fassade abfangen lassen. Beides trifft auf die meisten gewachsenen JavaScript- und Node-Plattformen zu, die über Jahre gewartet und erweitert wurden und im laufenden Betrieb bleiben müssen.
Es passt nicht überall. Wenn ein System klein genug ist, um es in wenigen Wochen vollständig zu ersetzen, kostet die Übergangsarchitektur mehr, als sie einspart. Und wenn der Quellcode des Altsystems nicht zugänglich ist oder sich Anfragen technisch nicht abfangen lassen, etwa bei stark eingebetteten Legacy-Komponenten ohne klare Schnittstelle, fehlt die Voraussetzung für die Fassade komplett. Die folgende Übersicht zeigt, wo die drei gängigen Ansätze jeweils stehen.
| Ansatz | Risiko | Time-to-Value | Wann sinnvoll |
|---|---|---|---|
| Big-Bang-Rewrite | Hoch, ein einziger Cutover-Termin entscheidet alles | Erst am Ende, wenn er fertig wird | Kleines System, klarer Zeitrahmen |
| Strangler Fig Pattern | Niedrig, jede migrierte Domäne ist einzeln rückrollbar | Kontinuierlich, Domäne für Domäne | Großes oder geschäftskritisches System im laufenden Betrieb |
| Reines Refactoring | Niedrig, löst aber keine Architekturgrenzen auf | Kontinuierlich, begrenzt auf bestehende Struktur | Architektur ist im Kern brauchbar, nur Qualität fehlt |
4. Drei Fallen bei der Ablösung
Die Datenbank bleibt gemeinsam
Die häufigste Falle liegt nicht im Code, sondern in der Datenbank. Solange Alt- und Neusystem auf dieselben Tabellen zugreifen, bleibt die Ablösung technisch unvollständig, egal wie viel Anwendungslogik schon migriert ist. Ein Weg heraus: domänenspezifische Tabellen schrittweise in eine eigene Datenbank für den neuen Service extrahieren und über Change Data Capture zwischen beiden Datenständen synchronisieren, bis der neue Datenbestand geprüft und führend ist. Erst danach werden die alten Tabellen und Synchronisationsprozesse entfernt, nicht davor.
Die Ablösung endet nie
Ohne festen Fahrplan wird aus der schrittweisen Migration ein Dauerzustand: Es gibt immer eine dringendere Aufgabe als die nächste Domäne, und das Altsystem bleibt formal aktiv, aber praktisch traut sich niemand mehr, es weiterzuentwickeln. Dagegen hilft nur eine Liste aller Domänen mit Fortschritt und Termin, die regelmäßig vor dem Management liegt, und ein Budget, das für Migration reserviert ist statt nur für neue Features. Ohne diesen Rahmen ist selbst das beste Muster nur eine Ausrede, den Rewrite auf unbestimmte Zeit zu verschieben.
Doppelter Betrieb wird zur Dauerlast
Solange beide Systeme laufen, verdoppelt sich ein Teil der Betriebsarbeit: zwei Deployments, zwei Monitoring-Setups, im Zweifel zwei Bereitschaftsdienste. Dazu kommt die Fassade selbst, die zur zentralen Schwachstelle wird, wenn sie nicht sauber überwacht ist. Fällt sie aus, fällt der Zugriff auf beide Systeme gleichzeitig aus, nicht nur auf eines. Wer das unterschätzt, plant die Migration nach Aufwand für neue Features, aber nicht nach dem laufenden Mehraufwand für den Parallelbetrieb, und wundert sich, warum das Team trotz Fortschritt keine Kapazität für Neues hat. Diese laufende Priorisierung braucht jemanden, der sie über Monate durchhält, oft eine Aufgabe für einen Interim CTO, wenn die Rolle im Team gerade nicht besetzt ist.
5. Refactor, Rewrite oder Strangler Fig
Drei Fragen entscheiden, welcher Ansatz passt. Ist die grundlegende Architektur brauchbar und fehlen nur Tests, Dokumentation und Aufräumarbeit, reicht reines Refactoring, wie es in den Strategien gegen technische Schulden beschrieben ist. Muss sich dagegen die Architektur selbst ändern, etwa von einem monolithischen Datenmodell zu klar getrennten Domänen, wie im Vergleich Monolith gegen Microservices, braucht es einen Systemwechsel, und die Frage ist nur noch, auf einmal oder schrittweise.
Genau hier setzt das Strangler-Fig-Muster an: als schrittweiser Weg für Systeme, die während der Migration weiterlaufen müssen. Bevor diese Entscheidung fällt, hilft ein nüchterner Blick darauf, was tatsächlich im Code steckt, statt nur auf die Einschätzung des Teams zu vertrauen. Wie automatisierte und menschliche Prüfung dabei zusammenspielen, steht in Was KI in einer Codebase findet, und was nicht.
Fazit
Das Strangler-Fig-Muster ist kein Werkzeug, das eine schlechte Entscheidung erspart, es verschiebt nur, wann sie fällig wird: nicht an einem einzigen Cutover-Termin, sondern Domäne für Domäne, mit der Möglichkeit, nach jeder einzelnen zurückzurudern. Für gewachsene JavaScript- und Node-Systeme, die ein Unternehmen tragen, ist das meistens der ehrlichere Weg als der Big-Bang-Rewrite, der auf dem Papier schneller aussieht und es in der Praxis selten ist.
Bevor eine dieser Entscheidungen fällt, zahlt sich ein klarer Blick auf den bestehenden Code aus. Genau das ist der Kern der Codebase Decision: in drei Tagen Klarheit, ob Refactor, Rewrite oder Ship-as-is für die eigene Situation am wenigsten kostet.