The strangler fig pattern
The strangler fig is a parasitic plant. It wraps around its host bit by bit and draws off its nutrients, until the host withers and the fig grows vigorously in its place, hence “strangling”. So the core of the strangler fig pattern fits in one line too: “grow gradually, take over gradually, replace gradually, remove gradually.”
It’s a fairly interesting design pattern. The scenario it’s aimed at is when the old business logic is dated, refactoring is hard and the tail’s too big to wag, and you still want to bring in newer, more modern technology. That’s when you reach for this pattern. The key to it is maximizing compatibility and isolation: keep the new feature’s boundary strictly inside the new feature, and expose a compatible old interface outward. The old system will coexist with the new one over a foreseeable stretch of time, until the new system has completely and safely taken over every function the old one implemented.
Against a Big Bang Rewrite that tears the old system down entirely, gradual, incremental replacement is obviously safer and cheaper. What usually pairs with this pattern is microservices: isolate the old system behind a proxy layer, and everything before it stays as it was while everything after it is new. When something goes wrong the proxy layer also becomes a shield that isolates the risk, so pulling one hair doesn’t move the whole body and leave you with a failed refactor and every old feature broken as well. On the frontend the equivalent is micro-frontends built mostly on the islands pattern, which is essentially the container idea taken to full modularity. Since there isn’t much coupling to begin with, the impact stays minimal. Its naturally modular architecture also makes testing very convenient. Inside and outside aren’t coupled, inputs and outputs are explicit, and it’s light work to test.
So a frontend refactor can go like this: bring single new feature modules into the old project gradually in micro-frontend form, built internally with a modern framework like Angular or React. At the same time, make sure the compiled output and the calls into it stay compatible under the old system as a whole. As far as the old system is concerned, it doesn’t see a “new thing” appearing here, it sees “business as usual” (the same way a parasitized host feels nothing while its nutrients are already draining away). The key, the real key, is keeping the whole migration reliable and controllable: hold problems inside a bounded range, and build a convenient way to roll back at any time, ideally a one-click uninstall.
Second, you can’t only mind isolation at the feature level, you have to make sure the data is isolated too. Data handling needs an anti-corruption layer so the old data structures don’t contaminate the new module and cause serious hidden data dependencies. Say there’s some special field that depends on an old feature. If the new module reads it directly, then once the old module is removed later, this spot blows up.
For the frontend in particular, isolation at the CSS level matters just as much. It isn’t only that the old system’s global styles will contaminate the new system’s, it goes the other way too. A UI library like Tailwind CSS may carry a CSS Reset, and once I mount it onto the old system’s interface it can travel up the whole pipeline and rewrite all the old system’s styles as well. So this counts as a boundary problem you have to think about.
That said, if parts of the old business are heavily coupled with a lot of state dependencies, then forcing a new architecture in there isn’t a good fit. Being able to get clear boundaries is always the precondition for replacement, with the two sides talking only through contract structures. The new part shouldn’t be sharing a lot of state with old pages, otherwise the moment you take the old one apart the new one is done for.
Translation note. I wrote this in Chinese. This English version is an LLM translation, so the wording is not mine even though the thinking is. Original: 絞殺榕模式.