Strangler Fig Pattern
A migration strategy where you gradually replace a monolith by routing features one by one to new microservices, until the old system can be decommissioned.
What is Strangler Fig Pattern?
In short
The Strangler Fig Pattern is a migration strategy where you incrementally replace an old system, usually a monolith, by building new functionality as separate services and routing traffic to them one feature at a time, until the old system handles nothing and can be shut off. It avoids a risky big-bang rewrite by running old and new code side by side behind a routing layer.
What it is
The pattern is named after the strangler fig, a vine that grows around a host tree, slowly taking over until the original tree is gone but the shape remains. Martin Fowler borrowed the image in 2004 to describe replacing a legacy system the same way: grow the new system around the edges of the old one instead of rewriting everything at once.
In practice you put a routing layer (often called a facade) in front of the legacy application. Requests still go to the old system by default. As you rebuild each feature in a new service, you flip the router so that feature's requests go to the new code instead. The old system keeps serving everything you have not migrated yet.
Over weeks or months the new system takes over more and more functionality. When the last feature has been moved and traffic to the legacy app drops to zero, you decommission it. Nothing is ever shut off before its replacement is live and proven.
How it works under the hood
The core mechanism is interception. You sit a proxy, API gateway, or reverse proxy between clients and the monolith. Tools like NGINX, an AWS Application Load Balancer, or an API gateway match on path, header, or hostname and forward each request to either the legacy backend or a new service.
A typical rule looks like: send any request to /checkout to the new checkout-service, send everything else to the monolith. As you migrate more endpoints, you add more rules. Because the routing is data driven, you can move one endpoint at a time and roll it back instantly by changing a single rule if the new service misbehaves.
The hard part is shared data. The monolith and the new service often read and write the same database tables during the transition. Teams handle this with a shared database for a while, an anti-corruption layer that translates between old and new data models, or change data capture and dual writes to keep both copies in sync until the legacy store can be retired.
When to use it and the trade-offs
Reach for the strangler fig when the system is too large or too business-critical to rewrite in one shot, when you cannot afford downtime, and when you want to ship value continuously instead of disappearing for a year on a rewrite that may never land. Each migrated slice goes to production on its own, so you get feedback early and reduce the blast radius of any single change.
The cost is that you run two systems at once for the whole migration, which means double the infrastructure, double the monitoring, and the routing facade itself becomes something you must keep healthy. Data consistency between old and new is the usual source of bugs.
The biggest failure mode is never finishing. If the migration loses funding or attention halfway, you are stuck maintaining both systems forever, which is worse than either one alone. A clear endpoint-by-endpoint plan and a commitment to delete the legacy code are what make the pattern work.
A concrete real-world example
Imagine an e-commerce monolith that handles auth, catalog, cart, and payments in one codebase. You start by putting an API gateway in front of it. First you build a new payments service, point /payments at it, and watch it for a few weeks while the rest of the app stays on the monolith.
Once payments is stable, you carve out the catalog into its own service and reroute /products and /search. Then cart, then auth. Each move is independent and reversible. After the last route is migrated, the monolith receives no traffic and you delete it.
Shopify, Amazon, and many banks have used this exact approach to break apart large legacy systems over multiple years without a single high-risk cutover weekend.
Where it is used in production
Amazon
Broke its early monolithic Obidos retail application into hundreds of services by routing features out one at a time rather than rewriting it wholesale.
Shopify
Extracted parts of its large Rails monolith into separate components behind internal routing while keeping the storefront fully online.
NGINX
Commonly used as the reverse proxy facade that matches request paths and forwards each one to either the legacy backend or a new service.
AWS
Application Load Balancer path-based and host-based routing rules are a standard way to incrementally shift traffic from a monolith to new services.
Frequently asked questions
- Why is it called the strangler fig pattern?
- It is named after the strangler fig vine, which grows around a host tree and gradually replaces it until the tree is gone. Martin Fowler used the image in 2004 for replacing a legacy system the same way: the new system grows around the old one and slowly takes it over.
- How is it different from a big-bang rewrite?
- A big-bang rewrite builds the entire replacement, then switches over on one high-risk day. The strangler fig migrates one feature at a time into production, runs old and new side by side, and lets you roll back a single feature instantly. It trades a long uncertain project for steady, reversible progress.
- What handles the routing between old and new code?
- A facade in front of the system, usually a reverse proxy or API gateway such as NGINX or an AWS Application Load Balancer. It matches each request by path, header, or host and forwards it to either the legacy backend or a new service, based on rules you update as you migrate.
- What is the biggest risk with this pattern?
- Never finishing. If the migration stalls halfway, you end up maintaining both the old and new systems indefinitely, which is more expensive and complex than either alone. Data consistency between the two systems during the transition is the other common source of bugs.
- How do you handle a shared database during migration?
- Options include letting both systems share the database temporarily, adding an anti-corruption layer that translates between the old and new data models, or using change data capture and dual writes to keep both stores in sync until the legacy database can be retired.
Learn Strangler Fig Pattern hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on Strangler Fig Pattern as part of a larger topic.
See also
Related glossary terms you might want to look up next.
Monolith
A single, unified application where all features share the same codebase and deployment. Simpler to start with but harder to scale individual parts.
Microservices
An architecture where an application is split into small, independent services that communicate over the network. Each service owns its own data and can be deployed separately.
API Gateway
A single entry point for all client requests that routes them to the appropriate microservice. Handles auth, rate limiting, and request transformation.
Service Discovery
The mechanism by which microservices find and communicate with each other. Services register themselves and others can look them up by name.
Circuit Breaker
A pattern that stops calling a failing service after repeated failures, preventing cascade failures. Like an electrical circuit breaker that cuts power to prevent fires.
Bulkhead
A pattern that isolates different parts of a system so a failure in one part doesn't sink the whole ship. Named after the compartments in a ship's hull.