Strangler Fig Pattern

What Is the Strangler Fig Pattern?

The Strangler Fig pattern — named after the tropical tree that grows around a host tree and eventually replaces it — is the safest, most battle-tested approach to incrementally migrating a legacy monolith to microservices. Rather than attempting a risky "big bang" rewrite, you route a small slice of traffic to new services while the monolith remains operational. Over time, the new services absorb more and more responsibility until the old system can be decommissioned.

Martin Fowler popularized the pattern in 2004. Amazon, Netflix, and LinkedIn all used variations of it when breaking apart their early monoliths. It is the answer an interviewer wants to hear when you are asked: *"How would you migrate a 10-year-old Rails monolith to microservices without taking the site down?"*

The Three Phases

1. Transform — Build the new service in parallel. It speaks the same external API contract as the monolith for the targeted capability.
2. Co-exist — Deploy a facade (reverse proxy or API gateway) in front of both systems. Route a subset of traffic (feature flag, cookie, user segment) to the new service. The monolith still handles everything else.
3. Eliminate — Once the new service proves reliable, shift 100% of traffic and retire the legacy code path.

Facade Implementation Options

The facade is the critical piece. You have several implementation choices depending on your traffic type:

Data Migration Strategy

The hardest part of any Strangler Fig migration is the data. The monolith and the new service cannot share a database long-term, yet they must stay consistent during the transition. A common approach is the Parallel Run with a sync bridge:

1. New service gets its own database (initially empty or bootstrapped from a snapshot).
2. A sync bridge (CDC — Change Data Capture via Debezium, or dual-write logic) keeps both databases in sync during the migration window.
3. Once traffic has fully shifted to the new service, the sync bridge is removed and the legacy table is archived.

Feature Toggles for Safe Rollout

Combine the Strangler Fig facade with feature toggles (feature flags) to route traffic to the new service by percentage, user segment, or region. This enables gradual exposure: start at 1% of users, watch error rates and latency, then ramp to 10%, 50%, 100%. If something goes wrong, flip the toggle back to the monolith instantly — no deployment required.

# Nginx example: route /orders to new service, everything else to monolith
upstream monolith {
  server legacy-app:8080;
}

upstream orders_svc {
  server orders-service:8080;
}

server {
  listen 80;

  location /api/orders {
    proxy_pass http://orders_svc;
  }

  location / {
    proxy_pass http://monolith;
  }
}

Rollback Strategy

A migration without a rollback plan is a gamble. Before cutting over any traffic slice, define your rollback triggers: error rate threshold (e.g., > 0.5%), p99 latency increase (e.g., > 200 ms above baseline), or on-call engineer manual override. The facade makes rollback trivial — a single config change redirects traffic back to the monolith.

Real-World Example: Netflix

Netflix migrated its DVD-era monolith to microservices between 2008 and 2012. They used a strangler approach: each team extracted a domain (streaming, recommendations, billing) behind a shared API gateway (Zuul). At peak migration, Netflix ran hundreds of simultaneous A/B experiments routing subsets of traffic to new service versions while the monolith served the remaining users. The migration took four years — a reminder that the Strangler Fig is a marathon, not a sprint.