Strangler Fig Pattern
An architectural pattern for incrementally replacing a monolith by routing functionality to new components step by step.
Classification
- ComplexityMedium
- Impact areaTechnical
- Decision typeArchitectural
- Organizational maturityIntermediate
Technical context
Principles & goals
Use cases & scenarios
Compromises
- Inconsistent data states without proper synchronization
- Missing rollback strategies may cause outages
- Too slow migration prolongs technical debt
- Start with well-bounded, loosely coupled features
- Ensure observability and end-to-end tests
- Use feature flags and canary releases
I/O & resources
- Monolith source code and architecture diagrams
- Routing infrastructure (API gateway, load balancer)
- Automated tests and monitoring
- Modularized, incrementally extracted services
- Reduced monolith and clear interfaces
- Metrics for stability and performance evolution
Description
The Strangler Fig Pattern enables incremental modernization of legacy systems by developing new functionality alongside the monolith and progressively routing traffic to it. It reduces big-bang risks and supports incremental testing and releases during migration. Suitable for high-risk, complex replacements while keeping the system operational.
✔Benefits
- Reduces risk through phased migrations
- Enables parallel development and testing
- Gradually improves maintainability and scalability
✖Limitations
- Requires additional routing and integration infrastructure
- Can create temporary complexity and duplicate efforts
- Not always suitable for highly cohesive, transactional domains
Trade-offs
Metrics
- Percentage of routed requests
Measures the percentage of traffic already routed to new components.
- Mean Time To Recover (MTTR) on rollbacks
Time required to restore a stable state after a failed cutover attempt.
- Error rate of new components
Observed error rates after incremental switching compared to the monolith.
Examples & implementations
Legacy shop to microservices
An online shop extracts checkout and inventory into separate services to improve scaling and release frequency.
Monolithic booking platform
A booking platform moves payment logic and notifications sequentially into new services to minimize risk.
Frontend to microfrontend migration
The frontend is extracted module by module from the monolith and integrated via gateway routing.
Implementation steps
Analyze and prioritize functionality to extract
Build infrastructure for routing and observability
Incremental extraction, testing, canary rollouts and monitoring
Iteratively remove old monolith parts after stabilization
⚠️ Technical debt & bottlenecks
Technical debt
- Temporary duplication of logic in monolith and new services
- Old data models remain longer
- Fragmented observability approaches during transition
Known bottlenecks
Misuse examples
- Extracting large transactional domains without a data strategy
- Omitting observability during critical cutovers
- Uncoordinated team actions causing inconsistencies
Typical traps
- Underestimating data migration effort
- Poor API designs increase long-term technical debt
- Decoupling infrastructure dependencies too late
Required skills
Architectural drivers
Constraints
- • Existing legacy database structure may hinder extraction
- • Limited time windows for changes in production
- • Regulatory requirements for data storage and integrity