We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Microservices Architecture
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.
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.
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.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Strangler Fig Pattern across a run of lessons, not one page. These 4 alone are about 89 minutes of step-by-step reading, every one with a quiz.
Migrate from monolith to microservices incrementally, replacing pieces one at a time while the old system stays alive.
Swap algorithms at runtime without touching the code that uses them, polymorphism done right.
Running two versions at once, everything they have to share, and why the weight change is the easiest part of it.
Using a primary until something says it is broken, why the detection is the whole problem, and why the standby is usually broken too.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Strangler Fig Patternpay once,
yours for life
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
This page explains the idea. The "Strangler Fig Pattern" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Strangler Fig Pattern lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Strangler Fig Pattern in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
