graph LR
A[Client] --> B(API Gateway);
B --> C((Monolith));
The Strangler Fig Pattern, inspired by the namesake plant’s growth, is a powerful strategy in software architecture for migrating monolithic applications to microservices or modernizing legacy systems without significant downtime or disruption. It allows for gradual, iterative refactoring, reducing risk and enabling continuous delivery. This post will look at the pattern, exploring its benefits, drawbacks, and practical implementation.
The Strangler Fig, a parasitic plant, begins its life by germinating in the canopy of a host tree. As it grows, it sends roots down towards the ground, eventually enveloping the host tree. This process is slow and gradual, allowing the fig to mature while the host continues to function. Similarly, the Strangler Fig Pattern in software gradually replaces a legacy system with a new architecture without completely shutting down the existing application.
The core idea is to create new microservices that gradually replace functionality from the monolith. Instead of a “big bang” migration, new features are implemented as independent microservices, and requests are incrementally routed to these new services. The existing monolith remains operational, acting as a fallback or handling functionality not yet migrated.
The key components are:
Let’s visualize this using Diagrams.
Phase 1: Initial State
graph LR
A[Client] --> B(API Gateway);
B --> C((Monolith));
Here, all requests go directly to the monolith.
Phase 2: Introducing a Microservice
graph LR
A[Client] --> B(API Gateway);
B --> C((Monolith));
B -- New Feature --> D(Microservice 1);
A new microservice handles a specific feature. The API Gateway routes requests for this feature to the new microservice.
Phase 3: Gradual Migration
graph LR
A[Client] --> B(API Gateway);
B -- Existing Feature --> C((Monolith));
B -- New Feature --> D(Microservice 1);
B -- Another Feature --> E(Microservice 2);
More microservices are added, gradually taking over more functionality.
Phase 4: Complete Migration (Ideally)
graph LR
A[Client] --> B(API Gateway);
B --> D(Microservice 1);
B --> E(Microservice 2);
B --> F(Microservice 3);
C((Monolith)) --> G[Deprecated/Removed];
The monolith is eventually decommissioned after all functionalities have been migrated. Note that this “complete” state is aspirational; parts of the monolith might remain indefinitely depending on the context.