- rtshkmr's digital garden/
- References/
- Architecture Design Basics/
- Pattern Taxonomy/
- Communication & API Design/
- Strangler Fig (API Migration)/
Strangler Fig (API Migration)
··
185 words·
1 min
Table of Contents
🟡 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 decommissionedThe 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 #
- original writing by Martin Fowler on strangler fig migration pattern
- more writings on the usage of this pattern here
- more general patterns of legacy displacement written by martin fowler / thoughtworks