The Strangler Fig Pattern

Grow the new around the old

Big-bang rewrites of large systems are notoriously risky: the old system keeps changing, the new one takes longer than planned, and the switchover day is terrifying. The strangler fig pattern (named by Martin Fowler after vines that grow around a host tree) replaces a system gradually. Put a routing layer in front of the monolith, usually a reverse proxy or API gateway. Build one new capability as a service and route just those requests to it, leaving everything else on the monolith. Repeat, capability by capability, until the monolith is small enough to retire, or until the remaining part is fine to keep. Each step is small, reversible (flip the route back) and delivers value. Choose early candidates that are relatively independent, change often or have clear scaling needs, and avoid starting with the most tangled core.

Strangling a monolith step by step

A router sends more and more paths to new services until little of the old system remains.

Routing one capability to a new service

Only /api/search moves; everything else still hits the monolith.

upstream monolith      { server legacy-app:8080; }
upstream search_service { server search.internal:8080; }

server {
    listen 443 ssl;

    location /api/search {
        proxy_pass http://search_service;    # new service
    }

    location / {
        proxy_pass http://monolith;          # everything else unchanged
    }
}

Measure before you switch

Run the new service in shadow mode first: send it a copy of real traffic, compare its responses with the monolith's, and switch the route only when results match.

Quick check: What is the main idea of the strangler fig pattern?

• Gradually route individual capabilities from the old system to new components
• Rewrite the whole system and switch over in one weekend
• Delete the database first
• Freeze all feature work for a year