Strangler Fig Pattern
- In Turkish
- Strangler Fig Deseni
In short
The strangler fig pattern is a way to replace a legacy system gradually by routing features to new code one at a time until the old system can be retired.
What is the strangler fig pattern?
The strangler fig pattern is a strategy for modernizing an old application, often called a legacy system, without a risky big-bang rewrite. Instead of building a complete replacement and switching over in one day, you build new functionality piece by piece next to the old system and move traffic over gradually. Martin Fowler named it in 2004 after strangler fig trees, which grow around a host tree until they replace it.
It usually works by putting a routing layer, such as a reverse proxy or API gateway, in front of the legacy system. At first, everything goes to the old code. As each feature, for example user profiles or invoicing, is rebuilt in the new system, the router sends those requests to the new implementation while everything else still goes to the old one. Once no traffic reaches the legacy code, it can be switched off.
Think of renovating a house room by room while still living in it, instead of moving out and demolishing it. Each finished room is usable right away, and if something goes wrong you only have to fix one room. The pattern is widely used to break a monolith into microservices, move applications to the cloud, or replace an outdated framework.
The strangler fig pattern is often confused with a full rewrite, which builds the whole new system before switching and pushes all the value and risk to a single cutover day. It also differs from refactoring, which improves code structure inside the existing system rather than replacing it. The main challenges are keeping data consistent while both systems run and avoiding a migration that stalls halfway, leaving the team maintaining two systems indefinitely.
Key takeaways
- Replace a legacy system gradually, one feature at a time, instead of in a single rewrite.
- A routing layer, such as a proxy or API gateway, decides which system handles each request.
- Each migrated piece delivers value early and can be rolled back on its own.
- Shared data and a stalled, half-finished migration are the main risks.
- It is a common way to move from a monolith to microservices.
Example
# Routing layer in front of both systems (illustrative gateway config)
routes:
# Already migrated: handled by the new services
- path: /api/profiles
target: http://profile-service:8080
- path: /api/invoices
target: http://billing-service:8080
# Everything else still goes to the legacy monolith
- path: /
target: http://legacy-app:8000Readers ask
Why is it called the strangler fig pattern?
Martin Fowler named it after strangler fig trees, which sprout on a host tree, grow around it over many years, and eventually replace it. The new system similarly grows around the old one until the old one can be removed.
When should you use the strangler fig pattern?
Use it when a large, business-critical system must be replaced but can't be frozen or switched off for a long rewrite. It works best when requests can be intercepted and routed, as with web applications and APIs.
What is the difference between the strangler fig pattern and a rewrite?
A rewrite builds a complete replacement and switches over all at once, which concentrates risk at the end. The strangler fig pattern migrates piece by piece, so each part goes live, gets feedback, and can be rolled back independently.
See also
- MonolithSoftware Architecture, p. 28A monolith is a software application built and deployed as a single unit, where all features share one codebase, one process, and usually one database.
- MicroservicesSoftware Architecture, p. 27Microservices are an architectural style where an application is split into small, independently deployable services that communicate over a network.
- RefactoringSoftware Architecture, p. 33Refactoring is the process of restructuring existing code to make it cleaner and easier to maintain without changing what the code does from the outside.
- Technical DebtSoftware Architecture, p. 45Technical debt is the future cost of extra work created when developers choose a quick or limited solution now instead of a better approach that takes longer.
- API GatewayBackend & APIs, p. 3An API gateway is a server that sits in front of a group of backend services and acts as the single entry point that receives, checks, and routes API requests.
- Reverse ProxyDevOps & Cloud, p. 44A reverse proxy is a server that sits in front of web servers, accepts client requests on their behalf, and forwards each request to the right backend server.
Spotted a mistake or something missing on this page?Suggest an edit