The Strangler Fig Pattern for Legacy System Refactoring

What's really being asked

This question tests your ability to think strategically about long-term technical debt and system evolution. It's not just about knowing a definition, but understanding the why: risk mitigation, continuous value delivery, and avoiding the catastrophic failures of "big bang" rewrites. The interviewer wants to see that you can manage a multi-year project without halting business feature development.

The full answer

First, define the pattern using its botanical metaphor: a new system (the fig) is built around the edges of a legacy system (the host tree). It starts small, grows over time by drawing nutrients, and eventually replaces the original, which can then be decommissioned. Second, outline the process: identify "seams" in the legacy system where you can intercept calls (like an API gateway or load balancer); build a new, separate service that replicates or improves a piece of functionality; use the seam to redirect traffic from the old component to the new one; and finally, monitor and repeat until the legacy component is fully replaced. Third, connect it to Agile frameworks by explaining how each strangled component is a small, deliverable increment of value that fits perfectly into sprints, providing measurable progress and enabling continuous feedback.

The mistakes people make

A major red flag is confusing the pattern with a "big bang" rewrite. The entire point of the Strangler Fig is to avoid a single, high-risk launch. Another common mistake is describing it as a simple lift-and-shift to the cloud; the pattern is about incremental functional replacement, not just re-hosting. A weak answer also fails to mention the transitional architecture required. Managing the period where both systems coexist, with its challenges in routing, data synchronization, and monitoring, is a critical part of the process. Finally, answers that don't connect the effort to business value—like enabling faster feature delivery or reducing operational risk—miss the strategic point.

What usually comes next

Expect questions like: "How would you identify the first part of the system to strangle?" (A: Look for low-risk, high-value areas, or parts undergoing active new development). Or, "What are the biggest risks with this approach?" (A: The transitional architecture can become complex; data consistency is hard; the project can lose momentum, leaving you with two systems to maintain indefinitely). You might also be asked for a concrete example of a "seam" (A: An API gateway, a reverse proxy like NGINX, a message queue, or a DNS change).

A concrete example

Imagine a monolithic e-commerce backend from 2010. The 'User Profile' page is slow and hard to change. Instead of rewriting the whole monolith, you deploy a new 'Profile Microservice'. You configure your API gateway (the seam) to route all requests for GET /api/users/{id} to the new service. The old monolith still handles POST /api/orders, but one piece of functionality has been successfully strangled. Next, you might tackle the 'Product Catalog' service. Over 2-3 years, you repeat this process until the original monolith handles zero traffic and can be shut down.