Strangler Fig Pattern

The Strangler Fig Pattern, named by Martin Fowler after the strangler fig tree that grows around a host tree and eventually replaces it, describes an incremental approach to replacing a legacy system by building a new system around the old one. The pattern proceeds in three stages: Transform (build the new capability in the new architecture), Co-exist (route some traffic to both old and new using a facade or API gateway), and Eliminate (retire the old component once the new handles all traffic). This approach eliminates the high-risk "big bang rewrite" anti-pattern while enabling continuous delivery of value throughout the migration.

Key Points

• The facade (API gateway or reverse proxy) is the control point for traffic routing — it allows percentage-based canary routing (1%→10%→50%→100%) to the new system while the legacy handles the remainder.
• Data migration is the hardest part — dual-write (write to both old and new databases during migration) + backfill (migrate historical data) + cutover (stop writing to old) is the standard sequence.
• Domain decomposition drives migration sequence — extract the bounded context with the most new feature demand first to deliver immediate business value and validate the new architecture.
• Anti-Corruption Layer translates between the legacy data model and the new domain model during the co-existence phase — prevents the new system from being polluted by legacy concepts.
• Branch by abstraction: introduce an abstraction over the legacy component, implement a new implementation behind the abstraction, toggle at runtime — enables migration without long-lived feature branches.
• Event interception: intercept events/messages at the integration layer rather than copying data — new service consumes the same Kafka topics or REST APIs as the legacy, then progressively takes over.
• Risk mitigation: the strangler fig allows rollback at any migration stage — if the new implementation fails, the facade redirects traffic back to legacy without a full incident.
• Migration metrics: track percentage of traffic handled by new system, error rate differential between old and new, and latency comparison — use these to gate migration progression.