External user or system
Backend & Runtime / Knowledge library
Strangler Fig Pattern
Replaces a legacy system gradually by routing capabilities to new implementations
Why learn Strangler Fig Pattern?
It lowers migration risk through incremental delivery
The problem it solves
It modernizes a system without one all-at-once rewrite
Where it came from
Strangler Fig Pattern is a software design pattern that replaces a legacy system gradually by routing capabilities to new implementations. Its guarantees and tradeoffs depend on the concrete implementation and operating context.
Build your understanding
Work through these exercises in order. Try the task before opening a reference.
- Define Strangler Fig Pattern and distinguish it from a neighboring concept.
- Choose a realistic task where Strangler Fig Pattern is appropriate.
- Identify a failure mode caused by misusing Strangler Fig Pattern.
- Interpret a small design or result involving Strangler Fig Pattern.
- Explain one tradeoff or limitation of Strangler Fig Pattern.
Documentation and sources
- Patterns of Enterprise Application Architecture (martinfowler.com)
Connect the ideas
Explore next
Real World Example
Modernizing the Legacy Logistics Ledger
A regional logistics firm managing a monolithic, decade-old shipment tracking system.
The business problem
The existing system is a monolithic codebase that has become too fragile to update, causing high maintenance costs and preventing the integration of modern real-time tracking features.
How this topic solves it
The Strangler Fig Pattern allows the firm to gradually replace the legacy system by routing specific capabilities to new, decoupled microservices, effectively strangling the old system until it can be decommissioned.
- Identify a single, isolated business capability within the legacy monolith to extract.
- Implement the selected capability as a new, independent service.
- Deploy an intercepting proxy or API gateway to route traffic for that specific capability to the new service.
- Verify the new service handles requests correctly while the legacy system remains the source of truth for other functions.
- Repeat the process for remaining capabilities until the legacy monolith is empty.
Shows how the API Gateway redirects traffic from the legacy monolith to a new service.
Traffic interceptor
Original system
Modern implementation
- Client → Request → API Gateway
- API Gateway → Route legacy traffic → Legacy Monolith
- API Gateway → Route migrated traffic → New Service
Expected business outcome
A modular, maintainable architecture that allows for continuous delivery of new features without the risk of a total system rewrite.
Limitations and checks
The primary trade-off is the increased complexity of managing distributed systems and network latency between the proxy and services; monitor this by tracking request round-trip times at the gateway.