The Strangler-Fig Pattern in Practice

The strangler-fig pattern is named after a tree that grows around its host until the host is no longer needed. In software, it means routing traffic to a new system capability by capability until the old system has nothing left to do. It is the only legacy modernization strategy I have seen finish on time.

Start with a gateway, not a service

The first thing we build is a routing layer that sits in front of the legacy system. It does nothing useful yet — it forwards every request unchanged. But it gives us a single chokepoint where we can, later, redirect a capability to a new implementation without touching clients. This gateway is the most boring and most important artifact of the whole migration.

Pick the capability, not the layer

Teams instinctively want to migrate “the data layer” or “the auth module.” That’s horizontal. The strangler works vertically: pick one business capability — say, “quote generation” — and move it whole, from UI to data. You finish a slice the business can feel, which buys you the political capital to do the next one.

func route(r *http.Request) http.Handler {
    // New service handles quote generation; everything else
    // still falls through to the legacy monolith.
    if strings.HasPrefix(r.URL.Path, "/api/quotes") {
        return newQuoteService
    }
    return legacyProxy
}

The data problem is the real problem

The new service needs data the legacy system owns. You have two choices: dual-write (both systems update together) or change-data-capture (the legacy system streams changes out). We prefer CDC via Debezium where the legacy database allows it — dual-write introduces a consistency window that will eventually bite you at 3am.

Finish a slice the business can feel. That buys the capital to do the next one.

The cutover is a tenant, not a switch

Never cut over all users at once. Route by tenant, by region, or by a percentage of traffic. If the new capability misbehaves, you roll back one tenant, not the company. We cut over Sentinel Mutual policy by policy over six weeks; the first tenant was internal users, the last was the noisiest customer. By the time we reached them, the system was boring — which is the goal.