Strangler Fig Pattern

The safe, incremental strategy for migrating a live monolith to microservices

⏱ 10 min📊 Diagram

Named after the strangler fig tree that grows around a host tree and eventually replaces it, this pattern lets you migrate a live production system without a risky Big Bang rewrite. 80% of Big Bang rewrites fail — the Strangler Fig succeeds by never stopping the old system until the new one fully replaces it.

Key Concepts

Never Stop the Monolith

The monolith serves 100% of traffic on day 1. You slowly drain it. No big-bang cutover. If something breaks, traffic re-routes back instantly.

API Gateway is the Key

All traffic enters through a Gateway (Nginx, Kong, AWS API GW). The gateway decides: send to monolith or new microservice. This is your routing table.

Extract Leaf Domains First

Start with domains with few incoming/outgoing dependencies: Notifications, Reviews, File Uploads. Save Orders and Payments for last — they have the most cross-domain calls.

Dual-Write During Transition

During cutover, write to both old and new DB simultaneously. Validate consistency. Only switch reads after confidence is established.

The Strangler Fig Pattern in Action

The 4-Step Strangler Fig Process

Step 1: Deploy API Gateway in front of Monolith — all requests go through it. Zero change to users.
Step 2: Extract one domain (e.g., /api/reviews) into a new Microservice with its own isolated DB.
Step 3: Update Gateway routing — /api/reviews routes to new service. Monolith code remains but now unused for this domain.
Step 4: Remove the dead code from the Monolith. Repeat for next domain. After all domains are extracted, decommission the monolith.

Routing Configuration Example (Nginx/Kong)

gateway.confnginx
# API Gateway routing config — Strangler Fig pattern
server {
    listen 80;

    # Phase 1: All legacy routes go to monolith
    location / {
        proxy_pass http://monolith:3000;
    }

    # Phase 2: Migrated route — /api/reviews now served by new microservice
    location /api/reviews {
        proxy_pass http://review-service:4001;
        # Canary: initially 10% traffic, then 100%
    }

    # Phase 3: Another extracted service
    location /api/notifications {
        proxy_pass http://notification-service:4002;
    }
}

Domain Extraction Order Strategy

Priority	Domain	Reason
1st (Easiest)	Notifications / Emails	Pure output, no shared state, fire-and-forget
2nd	Reviews / Comments	Read-heavy, minimal write coordination
3rd	User Profile	Self-contained, rarely shared schema
4th	Product Catalog	High read traffic — great scaling win once separated
Last (Hardest)	Orders / Payments	Complex cross-domain transactions, Saga pattern needed

💡

Senior Architect Insight: The strangler fig pattern has a secret superpower: it forces you to define a proper API contract between the new service and the rest of the system. If you can't draw a clean boundary, the domain isn't ready to be extracted yet.

PreviousWhy & When to Migrate

Next LessonDDD & Bounded Contexts