Instead of rewriting the entire application at once, new functionality is implemented as independent services while the existing monolith continues to serve the remaining functionality.
As more features are migrated, an increasing number of requests are routed to the new services until the monolith can be retired completely.
The pattern is named after the Strangler Fig tree, which gradually grows around another tree until it eventually replaces it.
Why Do We Need the Strangler Fig Pattern?
Large monolithic applications often contain millions of lines of code and years of accumulated business logic, making them difficult and risky to replace in a single migration.Instead of rebuilding the entire application at once, the Strangler Fig Pattern allows new functionality to be implemented as microservices while the existing monolith continues to serve the remaining features.
An API Gateway sits in front of both systems and routes requests to either the monolith or the appropriate microservice.
Client
|
v
API Gateway
/ \
/ \
v v
Monolith Microservices
Migration Process
Migration begins by identifying a business capability that can be extracted from the monolith with minimal dependencies. Suppose an e-commerce application initially consists of the following modules.
Monolith
|
+------+------+
| | |
Orders Inventory Payments
|
Customers
|
Notifications
Client
|
v
API Gateway
/ \
/ \
v v
Monolith Notification
Service
Step 1
API Gateway
|
+----------+----------+
| |
v v
Monolith Notification
Service
API Gateway
|
+----------+----------+
| | |
v v v
Monolith Notification Inventory
Service Service
API Gateway
|
+-----------+-----------+-----------+-----------+
| | | |
v v v v
Orders Inventory Payment Notification
Service Service Service Service
Database Migration
Migrating application code is only part of the Strangler Fig Pattern. The application's data must also be migrated gradually.Initially, the monolith typically owns a single shared database that contains data for multiple business capabilities.
Monolith
|
v
Shared Database
API Gateway
|
+-------+-------+
| |
v v
Monolith Inventory Service
| |
v v
Shared DB Inventory DB
To avoid duplicating or losing data, the newly extracted service may temporarily read or write data through the monolith until ownership is fully transferred.
Once the required data has been migrated and the new service becomes the authoritative owner, the monolith no longer accesses that data directly.
This process is repeated for each business capability until every microservice owns its own database, following the Database per Service pattern.
Advantages
1. The Strangler Fig Pattern significantly reduces migration risk because only small portions of the application are replaced at a time.2. New features can be delivered continuously while migration is in progress, allowing business development to continue without waiting for a complete rewrite.
3. Since each extracted service can be tested and deployed independently, problems are easier to isolate and recover from than in a large-scale replacement project.
Limitations
1. During migration, both the monolith and the new microservices must be maintained simultaneously, increasing operational complexity.2. The migration process may also take months or even years for large applications. Until migration is complete, duplicated functionality, temporary integrations, and shared data ownership may increase development effort.
Summary
The Strangler Fig Pattern provides a low-risk approach for migrating a monolithic application to microservices by extracting business capabilities one service at a time while the existing application continues to operate.Using an API Gateway for request routing and gradually adopting the Database per Service pattern, organizations can modernize legacy systems with minimal disruption while continuing to deliver new features throughout the migration.
