Skip to content

PATTERN Cited by 1 source

Strangler Fig

Definition

Strangler Fig (Martin Fowler, 2004) is the pattern of incrementally replacing a legacy system by routing requests through an interception layer — a proxy, gateway, or facade — that forwards each request to either the old implementation or a new one, service by service, until the new system has "strangled" the old one and the legacy code can be retired. The name comes from the strangler fig vine, which grows around a host tree until the original is gone.

The defining property is no big-bang cutover: the old and new systems run in parallel, the routing layer decides per-request (or per-service) which handles it, and migration status is a dial that can be turned one notch at a time — and turned back on failure. Each slice is migrated, validated, and cut over independently while everything else keeps running.

Why it exists

Rewriting a large, tightly-coupled, mission-critical system in one shot is the highest-risk form of migration: the new system must reach feature parity with years of accreted logic before it can carry any traffic, and the cutover is all-or-nothing. For systems that cannot take downtime — an airline retailing platform running shopping/pricing/booking around the clock, a payments core, an order system — a rewrite-and-swap is often unacceptable.

Strangler Fig converts that single catastrophic risk into a series of small, reversible ones. You get:

  • Incremental value + validation — ship and prove one service at a time; discover integration problems early on a small blast radius.
  • Reversibility — if a migrated service misbehaves, flip the routing dial back to the legacy implementation.
  • Parallel operation — the legacy system keeps serving everything not yet migrated, so there is never a window where the product is down.

Mechanism

  1. Insert an interception layer in front of the legacy system — a proxy / API gateway / facade. All client traffic now flows through it.
  2. Preserve the existing interface so clients don't change (backward compatibility). The proxy may also translate protocols (e.g. REST↔SOAP) so new and old speak different wire formats behind one facade.
  3. Extract one bounded context from the legacy system into a new implementation (often a microservice).
  4. Route that slice to the new implementation, everything else to the legacy system — ideally via a config flag / parameter so routing can be flipped (and un-flipped) without redeploying.
  5. Validate the migrated slice (often with dual-run reconciliation or non-regression testing against the old path), then move to the next bounded context.
  6. Repeat until the legacy system handles nothing and can be retired.

Seen in

  • Datalex airline-retailing modernization (AWS EBA, 2026) — a business service proxy routes each request to either the existing Java 8 / EJB2 n-tier system or the new Spring Boot / Java 21 microservice based on per-service migration status. AWS specifically advised a gateway that could route to the old REST API or the modernized API "through a simple parameter change," enabling rapid non-regression testing. Kong API Gateway additionally does REST↔SOAP protocol translation so new microservices interoperate with legacy SOAP services during the transition. The established pattern now targets ~4M remaining lines of code: identify bounded contexts → extract with dependency analysis → refactor to Spring → containerize → deploy in parallel with the existing system. (Source: sources/2026-10-01-aws-accelerating-airline-retailing-innovation-datalex-modernization)

Relationship to other patterns

  • patterns/shadow-migration — Strangler Fig decides which system serves a request; shadow migration validates a new implementation by running it in parallel and reconciling outputs before any consumer sees them. They compose: shadow-run a migrated slice, then flip the Strangler routing dial to it once reconciliation is clean.
  • patterns/staged-rollout — within a single migrated service, the old↔new routing dial can itself be rolled out as a canary / percentage split rather than an instant per-service flip.
  • concepts/monolith-vs-microservices-pendulum — Strangler Fig is the usual safe path when a team has decided to decompose a monolith/ n-tier system into services.

Trade-offs

  • The interception layer is a new dependency on the critical path — it adds latency and is itself a single point of failure if not made redundant.
  • Dual maintenance window: for the duration of the migration you run (and pay for, and operate) both systems, plus the routing layer and any protocol-translation glue.
  • Requires clean bounded contexts; extracting a slice from a tightly-coupled codebase needs dependency analysis and may force interim seams/anti-corruption layers. The harder the coupling, the more the proxy accumulates translation logic.
  • Migration can stall half-done — a strangler that never finishes leaves two systems and a proxy indefinitely, the worst of all worlds.
Last updated · 766 distilled / 2,225 read