The Strangler Pattern for Legacy Systems
For modernizing core systems like a mortgage LOS, the "strangler pattern" is gaining traction. A recent webinar explained the strategy: incrementally replace legacy modules with new microservices, using API adapters to bridge the old and new systems. This phased approach reduces the risk of big-bang rewrites while allowing for continuous delivery.
The term "Strangler Fig Pattern" was coined by software consultant Martin Fowler in 2004 after a trip to Australia, where he observed the massive strangler fig trees that grow by enveloping and eventually replacing their host trees. This natural process serves as a metaphor for incrementally replacing a legacy system with a new one, piece by piece, while the old system remains operational. At its core, the pattern utilizes a routing facade or proxy that sits in front of the legacy system. Initially, this proxy routes all traffic to the monolith. As new microservices are built to replace specific functionalities, the proxy is updated to divert corresponding requests to the new services, allowing for a gradual and controlled migration. This approach stands in stark contrast to the high-risk "big bang" rewrite, where a new system is developed in isolation and deployed all at once. Such projects are notorious for their massive upfront costs, extended timelines with no value delivery until the end, and the significant risk of discovering critical design flaws only after launch. In the financial sector, Garanti BBVA Technology has successfully used the Strangler Pattern to migrate monolithic architectures to event-driven services, enabling incremental value delivery and maintaining system stability during the transition. Another case study with a fintech company modernizing its payment processing system saw the full transition completed over 16 months, retiring the old system without disrupting users. While the pattern reduces risk, it introduces its own complexities. Teams must manage the overhead of running two systems in parallel, handle potential data consistency issues between the old and new databases, and navigate the interdependencies of a complex legacy system. The ultimate goal is for the new system of microservices to completely "strangle" the original monolith, at which point the legacy system can be safely decommissioned. This method allows organizations to continuously release new features and improvements throughout the lengthy modernization process, avoiding a complete halt in development.
