What is the Strangler Fig pattern for migrating a monolith to microservices?
Learn the Strangler Fig pattern for migrating a monolith to microservices incrementally, how the routing facade works, its benefits and steps.
Expected Interview Answer
The Strangler Fig pattern is an incremental migration strategy where you gradually replace pieces of a monolith with new microservices, routing traffic slice by slice until the old system can be safely retired.
Instead of a risky big-bang rewrite, you place a routing layer (often an API gateway or facade) in front of the monolith. New or extracted functionality is built as microservices, and the router redirects the relevant requests to them while everything else still hits the monolith. Over time more capabilities are strangled out of the old system until it is fully decommissioned. The name comes from the strangler fig vine that grows around a host tree and eventually replaces it.
- Reduces risk by migrating in small, reversible increments
- Delivers value continuously instead of after a multi-year rewrite
- Lets old and new systems run side by side
- Makes rollback of a single slice easy
- Avoids a costly and error-prone big-bang cutover
AI Mentor Explanation
Think of rebuilding a national team without dropping every senior player at once. Each series you blood one promising youngster into a settled role, let them prove themselves, and quietly retire the veteran they replace. The XI keeps winning throughout, and by the end the squad is entirely refreshed without a single disastrous rebuild season.
Step-by-Step Explanation
Step 1
Insert a routing facade
Put an API gateway or proxy in front of the monolith so requests can be redirected per route without clients noticing.
Step 2
Identify a seam
Pick a bounded capability with clear inputs and outputs and few tangled dependencies to extract first.
Step 3
Build the microservice
Reimplement that capability as an independent service with its own data ownership and API.
Step 4
Redirect traffic
Update the router to send the relevant requests to the new service, keeping everything else on the monolith.
Step 5
Verify and repeat
Monitor parity and errors, roll back if needed, then move on to the next capability.
Step 6
Decommission the monolith
Once no traffic reaches the old code paths, remove them and finally retire the monolith.
What Interviewer Expects
- Understanding that migration is incremental, not big-bang
- Role of the routing facade or API gateway
- How to choose seams and bounded contexts to extract
- Awareness of running old and new systems in parallel
- How data ownership and consistency are handled during transition
Common Mistakes
- Describing it as a one-time rewrite instead of gradual replacement
- Forgetting the routing layer that makes the migration transparent to clients
- Ignoring the shared-database problem during the transition
- Extracting a highly coupled component first instead of a clean seam
- Never actually decommissioning the monolith, leaving two systems forever
Best Answer (HR Friendly)
“The Strangler Fig pattern is a way to modernize an old system a little at a time instead of rebuilding it all at once. You slowly move features into new services while the old system keeps running, until eventually the old one has nothing left to do and can be switched off.”
Code Example
# Old requests still hit the monolith
location / {
proxy_pass http://monolith;
}
# The 'payments' capability has been strangled out
# and now routes to the new microservice
location /api/payments/ {
proxy_pass http://payments-service;
}Follow-up Questions
- How do you handle a shared database while strangling a capability out?
- How do you choose which part of the monolith to extract first?
- What is the difference between the Strangler Fig and a big-bang rewrite?
- How do you keep data consistent between the monolith and new services?
- When might the Strangler Fig approach be the wrong choice?
MCQ Practice
1. What is the primary goal of the Strangler Fig pattern?
The pattern replaces the monolith piece by piece while it keeps running, avoiding a big-bang rewrite.
2. Which component makes the migration transparent to clients?
A facade or gateway sits in front and redirects each route to either the monolith or the new service.
3. When is the monolith finally removed?
Once every capability has been strangled out and no requests hit the old code, it can be safely decommissioned.
Flash Cards
Where does the name come from? — The strangler fig vine that grows around a host tree and eventually replaces it.
What makes the migration transparent? — A routing facade or API gateway that redirects requests per route.
Big-bang vs Strangler Fig? — Big-bang rewrites everything at once; Strangler Fig replaces capabilities incrementally with rollback per slice.
What is the final step? — Decommissioning the monolith once no traffic reaches its remaining code paths.