What is the Strangler Fig pattern?

What's really being asked

This question tests your experience with real-world legacy modernization. The interviewer isn't looking for a textbook definition. They want to see if you understand the immense risk and cost of a 'big bang' rewrite and can articulate a practical, phased alternative. It assesses your strategic architectural thinking and your ability to connect a technical pattern to business goals like risk reduction and incremental value delivery within an agile framework.

The full answer

A strong answer explains the pattern through its metaphor and then details the implementation. First, define the pattern using the botanical analogy: a new system (the fig) grows around a legacy system (the host tree), gradually drawing functionality until the old system is 'strangled' and can be decommissioned. Second, outline the technical process: you identify 'seams' in the legacy system, which are logical boundaries for functionality. Third, you introduce a routing facade (like a reverse proxy or API gateway) that sits in front of the legacy system. Fourth, you build a new service to replace one piece of functionality and update the facade to route traffic for that specific feature to the new service. Finally, you explain this process is repeated for other features, which aligns perfectly with Agile principles by delivering small, valuable, and working increments, allowing for continuous feedback and learning.

The mistakes people make

The most common mistake is describing a 'big bang' rewrite, which is the exact opposite of this pattern. Another major red flag is forgetting to mention the routing facade. Without a mechanism to direct traffic between the old and new systems, the pattern is impossible to implement. A junior answer focuses only on the code; a senior answer connects the strategy to business outcomes, such as delivering a new feature to market in 3 months on the new platform, rather than waiting 2 years for a full rewrite. Finally, failing to mention the need for organizational change to support this ongoing, incremental process is a missed opportunity.

What usually comes next

Expect questions about the hard parts, such as: 'How do you manage data consistency between the new and old systems during the transition?'. Or, 'What are the risks of the Strangler Fig approach itself?', probing your awareness of challenges like maintaining a complex transitional architecture for a long period. They might also ask for a specific example, like 'How would you identify a seam in a monolithic e-commerce application?'.

A concrete example

Imagine a monolithic banking app where the 'Foreign Exchange' calculation is slow and hard to update. First, place an API Gateway in front of the monolith. Initially, it routes all traffic, including requests to '/api/fx-rate', to the old system. Next, build a new, independent 'FX Service'. Once it's ready, you reconfigure the API Gateway to route all '/api/fx-rate' requests to the new service. All other requests, like '/api/account-balance', still go to the monolith. You've delivered immediate value and de-risked the project. You then repeat this for the 'Account Balance' feature, and so on.