Strangler Fig Pattern

Introduction

Strangler Fig gradually replaces a legacy system by intercepting traffic at the edge — new routes go to the new system, unmatched routes fall through to legacy. Like the fig tree strangling its host, the new system grows until the legacy can be decommissioned. No big-bang rewrite.

The story

15-year PHP monolith couldn't stop for rewrite. NGINX router in front — new URLs to Java microservices, rest to PHP. Over 18 months 80% traffic on new stack without single cut-over.

The business problem

Big-bang rewrites fail and block feature delivery for years:

• Rewrite risk: years of work, never ships.
• Undocumented behavior: legacy edge cases lost in rewrite.
• Feature freeze: business can't wait for replatform.
• All-or-nothing cutover: high-stakes launch weekend.

The problem teams faced

Strangler Fig fits when:

• Legacy system must keep running during migration.
• Routes/features can migrate incrementally.
• Edge proxy or router can intercept traffic.
• Business needs continuous value during migration.

Understanding the topic

Intent: Incrementally replace legacy by routing at boundary until legacy strangled.

• Facade/Router — NGINX, API gateway, load balancer.
• New system — microservices for migrated routes.
• Legacy — default fallback for unmigrated paths.
• ACL Adapter — anti-corruption at legacy boundary.

Internal architecture

NGINX strangler routing:

# New checkout migrated
location /api/v2/checkout {
  proxy_pass http://checkout-service;
}
# Everything else still legacy
location / {
  proxy_pass http://php-monolith;
}

Visual explanation

Three diagrams cover strangler growth, routing, and ACL:

Informative example

Before / after — big-bang plan to strangler:

// ❌ Big-bang: rewrite entire monolith for 2 years, freeze features

// ✅ Strangler: route-by-route migration
// nginx.conf — week 1: migrate health check
location /health { proxy_pass http://new-platform; }
location / { proxy_pass http://legacy-php; }

// week 12: migrate product catalog
location /api/products { proxy_pass http://catalog-service; }

// Legacy shrinks as routes migrate — rollback is one config line

Execution workflow

Real-world use

Martin Fowler strangler fig article; NGINX/Envoy routing migrations; Amazon monolith-to-microservices; ACL patterns in DDD for legacy ERP.

Production case study

PHP monolith 18-month strangler:

• Legacy: 15-year PHP; big-bang deemed impossible.
• Decision: NGINX router; Java microservices per migrated URL.
• Outcome: 80% traffic new stack; features shipped throughout.

Trade-offs

• Pro: continuous delivery during migration; low cutover risk.
• Con: dual-system operational complexity during transition.
• Con: data sync between legacy and new — hard problem.

Decision framework

• Use for legacy replatform with incremental feature migration.
• Migrate by vertical slice (feature), not horizontal layer.
• Plan data strangler alongside code strangler.

Best practices

• Characterization tests on legacy before each slice migration.
• ACL isolates legacy vocabulary from new domain model.
• Monitor error rate per route during traffic shift.

Anti-patterns to avoid

• Big-bang rewrite "just one more year."
• Horizontal migration (all DB first) — no user value.
• New system calls legacy internals directly — bypass router.

Common mistakes

• Dual-write between legacy and new DB without sync strategy.
• Premature legacy decommission before route 100%.

Debugging tips

• Compare legacy vs new response for same route in shadow mode.

Optimization strategies

• Shadow traffic to new system before cutting over route.

Common misconceptions

• Strangler ≠ Branch by Abstraction only — routing at edge is key.
• Works with monolith host — not only microservices target.

Advanced interview questions

Summary

You can plan incremental strangler migrations, route at edge, and avoid big-bang rewrites. Tell the 18-month PHP story — if you can do that, you own Strangler Fig and complete Enterprise Architecture.