Strangler Fig Pattern
The Strangler Fig Pattern describes the incremental replacement of a legacy system: new code grows around the old system in parallel, gradually taking over individual functions until the legacy system is fully replaced and can be decommissioned. No big-bang rewrite, no system downtime.
The name comes from the fig species that slowly grows around a host tree and eventually replaces it.
Why Not a Big-Bang Rewrite?
Big-bang rewrites fail regularly: the new code must replicate all the functionality of the old system while simultaneously delivering new features, and exists for months without producing value in production. The risk is extremely high.
The Process
- Build a Facade / Proxy: An HTTP proxy or API gateway is placed in front of the legacy system. All requests initially pass through unchanged.
- Extract the First Use Case: A clearly bounded function (Bounded Context) is reimplemented in the new system.
- Redirect Traffic: The proxy now routes requests for this use case to the new system.
- Iterate: Steps 2 and 3 are repeated for further use cases.
- Decommission Legacy: Once all functions have been migrated, the legacy system is shut down.
Focus: Always Stay Deliverable
After every step, the overall system is production-ready. The business runs uninterrupted.
FAQ
How long does a Strangler Fig migration take?
It depends on the size of the legacy system. Six to twenty-four months is typical for a mid-sized system. The iteration must be consistent from the outset, otherwise a permanent parallel operation emerges.
What if the legacy system has no clear APIs?
The first step is to build an Anti-Corruption Layer (ACL) that cleanly encapsulates the legacy system. Only then can incremental migration begin.
Reference Guide
- Martin Fowler: Original description of the pattern. martinfowler.com/bliki/StranglerFigApplication.html
- Monolith to Microservices (Newman): Practical migration patterns. O'Reilly