strangler-fig.js·4 scenarios
Incremental monolith decomposition: proxy routing, CDC data sync, shadow traffic, phased migration
The Strangler Fig pattern is an incremental migration strategy for replacing legacy systems without the risk of a big-bang rewrite. Coined by Martin Fowler in 2004, the pattern is named after strangler fig trees -- tropical plants that germinate in the canopy of a host tree, send roots down to the ground, and gradually envelop the host until it is completely replaced.
In software, the host tree is the legacy monolith. The strangler fig is a set of new microservices that are built around the monolith, one domain at a time, until the monolith handles zero traffic and can be safely decommissioned.
This pattern is the dominant approach to monolith decomposition in the industry:
Web and mobile clients send requests over HTTPS. Clients are completely unaware of backend architecture changes -- the migration is invisible to them.
A proxy (API gateway, reverse proxy, or load balancer) sits in front of both the monolith and the new microservices. It intercepts every request and consults a route table to decide where to forward it. As migration progresses, routes are flipped from the monolith to the corresponding microservice one by one.
The original application that handles all domains in a single deployable unit with a shared database. It starts by handling 100% of traffic and gradually handles less as domains are extracted.
Each extracted domain (Users, Products, Orders) becomes an independent service with its own dedicated database. Services are built, tested, and switched over incrementally.
During the coexistence phase, Change Data Capture (CDC) tools like Debezium stream changes from the monolith database to the new service databases in real-time, ensuring data consistency while both systems are running.
The migration follows three phases. Transform: build the new microservice alongside the monolith. Coexist: run both systems in parallel, with the proxy routing traffic to the appropriate destination. Eliminate: once all traffic is routed to the new service and verified, remove the corresponding code and data from the monolith.
The strangler proxy is the central mechanism. It maintains a route table that maps URL patterns to backend services. Migrating a domain is as simple as updating a route: /api/users/* changes from MONOLITH to USER_SERVICE. The proxy makes the switch atomic and invisible to clients.
During migration, the same data may need to exist in both the monolith database and the new service database. CDC (Change Data Capture) captures row-level changes from the monolith database and replicates them to the new service database in real-time. This ensures both systems see consistent data during the coexistence phase. Once the route is fully switched, CDC replication is stopped and the data is cleaned up from the monolith.
Before switching a route, the proxy can send shadow (dark) traffic to the new service: requests are forwarded to both the monolith and the new service simultaneously. The monolith response is returned to the client while the new service response is compared for correctness. This validates the new service under real production load without any risk to users.
At any point during migration, the route table can be switched back to the monolith. There is no point of no return until the monolith code is actually deleted. This makes every migration step individually reversible, unlike a big-bang rewrite where rollback means abandoning months of work.
The Strangler Fig pattern exists specifically to avoid the big-bang rewrite -- the approach where the entire system is rebuilt from scratch and switched over in a single deployment. Big-bang rewrites are notorious for schedule overruns, feature gaps, and catastrophic failures on launch day. The Strangler Fig trades speed for safety: each domain is migrated independently, validated under real traffic, and rolled out with zero downtime.
Each domain follows a five-phase lifecycle: