100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace

What is the Strangler Fig Pattern?

Learn the strangler fig pattern: incrementally migrating a legacy monolith to new services via a routing facade, without a big-bang rewrite.

mediumQ201 of 224 in System Design Est. time: 5 minsLast updated:
Open Code Lab

Expected Interview Answer

The strangler fig pattern is an incremental migration strategy where a new system is built alongside an old monolith, gradually intercepting and replacing individual pieces of functionality behind a routing facade until the old system can be safely decommissioned.

Named after strangler fig vines that grow around a host tree and eventually replace it entirely, the pattern avoids a risky big-bang rewrite by placing a routing layer, such as a proxy or API gateway, in front of the legacy monolith. Each migrated capability is built as a new service, and the router is updated to send traffic for that specific capability to the new implementation while everything else continues flowing to the old system unchanged. Over time, more and more traffic is redirected to new services until the monolith handles nothing and can be retired. This approach keeps the system releasable and rollback-friendly at every step, because only a thin slice changes at a time, in contrast to a rewrite that delivers no value until it is entirely finished.

  • Avoids the risk of a big-bang rewrite that delivers no value until fully complete
  • Keeps the system in production and releasable throughout the migration
  • Allows each migrated slice to be validated and rolled back independently
  • Lets teams reprioritize or pause migration at any point without losing prior progress

AI Mentor Explanation

The strangler fig pattern is like gradually replacing an aging team’s starting eleven one position at a time across a season instead of benching the whole squad overnight for an all-new team. Each match, a selector swaps in one new player at a specific position while the rest of the proven lineup carries on unchanged, routing that position’s responsibilities to the new talent. If the new player underperforms, the selector can revert just that one position without disrupting the rest of the team. Season after season, more positions are replaced until the original starting eleven is gone entirely, replaced piece by piece.

Step-by-Step Explanation

  1. Step 1

    Introduce a routing facade

    Place a proxy, gateway, or feature-flagged router in front of the legacy monolith so traffic can be selectively redirected.

  2. Step 2

    Identify a slice to migrate

    Pick a bounded piece of functionality (a route, a domain, a feature) with clear boundaries and manageable risk.

  3. Step 3

    Build and cut over that slice

    Implement the new service for that slice, then update the router to send its traffic to the new implementation.

  4. Step 4

    Repeat and decommission

    Continue migrating slices incrementally; once the monolith handles no traffic, retire it entirely.

What Interviewer Expects

  • Explains the routing facade as the core mechanism enabling incremental cutover
  • Contrasts it explicitly with a risky big-bang rewrite
  • Mentions rollback-friendliness: each slice can be reverted independently
  • Recognizes the pattern applies to migrating monoliths to microservices or to swapping any legacy component

Common Mistakes

  • Describing it as simply “rewriting the app in pieces” without mentioning the routing/facade layer
  • Ignoring the need for the old and new systems to coexist and interoperate during migration (e.g., shared data)
  • Assuming migration is risk-free just because it is incremental — data consistency during the transition still needs care
  • Forgetting that the pattern’s value is continuous releasability, not just eventual full replacement

Best Answer (HR Friendly)

The strangler fig pattern is a way to replace an old system gradually instead of all at once. You put a router in front of the old system, build new pieces one at a time, and redirect traffic to each new piece as it becomes ready, while everything else keeps running on the old system. Eventually every piece has been replaced and you can turn off the old system, without ever having done one giant risky rewrite.

Code Example

Routing facade directing traffic between legacy and new services
const MIGRATED_ROUTES = new Set(["/api/orders", "/api/inventory"])

async function routeRequest(req, res) {
  const path = req.path

  if (isMigrated(path)) {
    // slice already strangled: send to the new microservice
    return proxyTo(NEW_SERVICE_URL, req, res)
  }

  // everything else still flows to the legacy monolith
  return proxyTo(LEGACY_MONOLITH_URL, req, res)
}

function isMigrated(path) {
  for (const prefix of MIGRATED_ROUTES) {
    if (path.startsWith(prefix)) return true
  }
  return false
}

// as more capabilities are rebuilt, their prefixes are added to
// MIGRATED_ROUTES until the legacy monolith receives no traffic at all

Follow-up Questions

  • How do you handle data consistency when the legacy monolith and new services both need access to the same data during migration?
  • What criteria would you use to decide which slice of a monolith to migrate first?
  • How is the strangler fig pattern different from a big-bang rewrite in terms of risk and delivery cadence?
  • When would you decide the migration is complete enough to decommission the legacy system?

MCQ Practice

1. What is the core mechanism that enables the strangler fig pattern?

A routing layer in front of the legacy system lets traffic be redirected slice by slice to new implementations, enabling incremental migration.

2. What is the main risk the strangler fig pattern is designed to avoid?

Big-bang rewrites are risky and delay value delivery; the strangler fig pattern migrates incrementally so the system stays releasable throughout.

3. What happens to the legacy system once migration is complete under this pattern?

As slices of functionality are migrated, the legacy system is “strangled” until it handles no traffic, at which point it can be safely retired.

Flash Cards

What is the strangler fig pattern?An incremental migration strategy using a routing facade to gradually replace a legacy system with new services.

Where does the name come from?Strangler fig vines that grow around a host tree and eventually replace it entirely.

Main alternative it avoids?A risky big-bang rewrite that delivers no value until fully complete.

Key enabler of the pattern?A proxy or gateway that can route traffic per-slice between the legacy system and new services.

1 / 4

Continue Learning