What is the Strangler Fig pattern and its use in legacy modernization?

What's really being asked

This question tests whether you understand incremental modernization as a strategic alternative to high-risk rewrites. Interviewers want to see that you grasp the organizational and technical mechanics of gradually replacing a legacy system while continuing to deliver business value. It also checks if you know the specific terminology and can connect it to agile principles like early feedback, iterative delivery, and risk reduction.

The full answer

First, the botanical metaphor itself: a vine that germinates in a host tree, grows roots and canopy, becomes self-sustaining, and eventually replaces the host. Second, the technical approach of building new functionality alongside the legacy system rather than inside it, often using an anti-corruption layer or facade to route requests incrementally from old to new components. Third, the concept of finding seams in the legacy codebase to isolate replaceable parts, since legacy systems rarely have clear component boundaries. Fourth, the four activities defined by Ian Cartwright, Rob Horn, and James Lewis: understand the outcomes you want, break the problem into smaller parts, deliver those parts successfully, and change the organization to sustain this practice. Fifth, the necessity of transitional architecture to bridge old and new during the migration.

The mistakes people make

A red flag is proposing a big-bang rewrite where users wait months or years for new features. Another is suggesting you must fully understand every detail of legacy behavior before starting; in reality much legacy behavior is unwanted and discovering this is part of the process. Saying the pattern is only about microservices is also wrong; while it pairs well with service extraction, the core idea is incremental replacement regardless of target topology. Finally, ignoring organizational change and treating modernization as purely a technical exercise signals immaturity.

What usually comes next

Interviewers may ask how you would identify seams in a monolith with no clear boundaries. They might probe how to handle data migration when strangling a system with a shared database. Another common follow-up is how to manage the business case when running two systems in parallel, or how to decide which components to strangle first.

A concrete example

Suppose a retail company has a twenty-year-old mainframe order system. Instead of rewriting it entirely, the team builds a new pricing service that sits behind an API gateway. The gateway routes pricing requests to the new service while order fulfillment stays on the mainframe. Over six months, the team extracts inventory, then customer lookup, each time redirecting traffic through the gateway. Eventually the mainframe handles only a small reporting module, which is then replaced. The business receives better pricing and inventory capabilities within weeks rather than waiting two years.