Skip to main content
  1. References/
  2. Architecture Design Basics/
  3. Pattern Taxonomy/
  4. Communication & API Design/

Strangler Fig (API Migration)

·· 185 words· 1 min

🟡 P2 — Martin Fowler’s pattern for incremental migration from monolith to microservices

Problem #

You can’t rewrite a running system from scratch. Big-bang migrations fail. You need to incrementally replace the old system while it continues serving traffic.

Mechanism #

Phase 1: All traffic → Old System
Phase 2: New proxy intercepts some routes → New Service
         Remaining routes → Old System (unchanged)
Phase 3: More routes migrated, old system shrinks
Phase 4: Old system decommissioned

The proxy (or API gateway) acts as the strangler: it gradually routes traffic away from the old system to new services, one endpoint at a time.

Key Trade-offs #

  • Safety: Each migration step is small and reversible. Rollback = route traffic back.
  • Cost: You’re running two systems in parallel during migration. Operational burden doubles.
  • Data: The hardest part is usually the data migration, not the API routing. Old and new systems may need to share a database temporarily.

Instinct #

Always use Strangler Fig for migrations, never big-bang. The question in interviews is usually about the data layer: how do you handle the shared database? Dual-write? Change Data Capture? See also: Zero-Downtime Migrations.

Reference #