We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Microservices Architecture
Free preview: the first 2 parts of this 8-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Microservices Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A company has a 10-year-old monolith. 500,000 lines of code. It works, but it's slow to change, impossible to scale independently, and engineers dread touching it. The CTO announces: "We're rewriting everything in ."
18 months later: the rewrite is 60% done, the is still running in production (because the rewrite isn't ready), both systems need maintenance, the team is exhausted, and the business has lost 18 months of feature development. This scenario is so common it has a name: the Second-System Effect, described by Fred Brooks in The Mythical Man-Month.
Netscape tried a big-bang rewrite of their browser in 1998. It took three years and nearly killed the company. The original Netscape team disbanded and the project eventually became Firefox, but only after years of lost market share to Internet Explorer.
The Strangler Fig pattern offers a different approach. Named after the strangler fig tree, a tropical plant that grows around an existing tree, gradually replacing it until the old tree dies and the fig stands on its own, the pattern migrates a monolith to microservices incrementally. You don't rewrite everything. You extract one piece at a time, routing traffic to the new service while keeping the monolith running. Each extraction is small, testable, and reversible.
Martin Fowler coined the name in 2004 after seeing strangler figs in Queensland, Australia. The biological metaphor is precise: the new growth wraps around the old without killing it until the new structure is self-supporting.
The Strangler Fig pattern has three phases for each piece of functionality you extract:
| Phase | What Happens | Risk |
|---|---|---|
| 1. Extract | Build the new that replaces one piece of the monolith's functionality | Low. The new service doesn't serve traffic yet |
| 2. Route | Place a routing layer (, reverse proxy) in front of both systems. Route traffic for the extracted feature to the new service, everything else to the monolith | Medium. The new service must handle production traffic |
| 3. Remove | Once the new service is proven stable, remove the corresponding code from the | Low. The code isn't used anymore |
Repeat for each feature until the monolith is empty. The routing layer is the key. It lets you switch traffic between old and new systems without users noticing.
Critical rule: The monolith and new services run in parallel during the entire migration. If the new service has a problem, you flip the route back to the monolith. Every step is reversible.
Shopify used this approach to extract their checkout system. For months, a routing sent 1% of checkout traffic to the new service while 99% stayed on the monolith. They gradually increased the percentage as confidence grew. At no point was the migration all-or-nothing.